Better with Data

Share this post

Improving On-Boarding

betterwithdata.substack.com

Improving On-Boarding

Erika Pullum (Swartz)
Apr 28, 2020
Share this post

Improving On-Boarding

betterwithdata.substack.com

Starting a new technical role can be a frustrating pendulum between boredom and overwhelm.

Getting set up takes time, and once you are set up, you’ll have lots of questions as you get used to new tools, data, and codebases.

Twitter avatar for @data_stephanie
Stephanie Kirmer @data_stephanie
I’m working on some onboarding materials for our DS team. Besides the obvious, HR type things, what technical docs are you looking for as a mid-senior level data scientist when you walk in the door at new job?
11:48 PM ∙ Apr 22, 2020
125Likes22Retweets

On my team, we’ve developed a process to keep new hires moving and learning. We use 3 key documents to help coordinate the team to bring our new member up to speed.

They are :

  • An access / skills checklist

  • An onboarding journey doc

  • Our overview of how we organize our documentation

Access / Skills Checklist

This document is the workhorse of the three. It provides a week-by-week road map of tasks and skills. For this demo, I’ve generalized it for a fictional new associate, Jane Smith.

Colored squares identify where a skill is - need help, need practice, or solid. I use initials to indicate who is responsible. Sometimes I need to initiate something and then after that has occurred, the new hire will need to follow up.

A blue dot indicates something we know needs better documentation. Maybe there are directions, but they’re not up to date. Maybe there aren’t any written down yet. Once the new hire learns the skill, they’ll get initials in blue to indicate they need to create the documentation or fix what’s already there.

We’re on our third or fourth iteration of this list - every time we hire someone new we find something missing or something we could do better.

What works well

  • Every new hire refines your documentation

  • Give new hires a clear road map, week-by-week, for getting capable in the role

  • There’s something to do when peers / collaborators aren’t accessible - go get more green on the list

  • Balance learning styles by offering options & supporting learning by doing

What needs an upgrade

  • A checklist does a bad job communicating concepts

  • My ‘working’ doc is still missing the “why” column. The original did a great job telling you what to do but didn’t tell you why it mattered

  • As work picks up, new associates shift away from learning towards doing. I need to find a better way to create accountability through the entire onboarding process.

Onboarding Journey Doc

Checklists lack soul. The onboarding journey document is personalized by me for every new associate. It breaks down into five sections.

Key Reference Links

New hires are learning a lot very quickly. This list of links has the access / skills doc and a couple other key internal documents. My goal is to help associates quickly find help. I add links to this section as the new hire asks questions or gets stuck.

Peer Support Resources

I identify 1-2 key team members who will support the new hire’s learning and answer questions as they pop up.

Week by Week Schedule

This section ties the access / skills list to the onboarding journey. Weeks 1-2 are all about basic access, weeks 3-6 are about building core skills for the role.

One of the key ways we do this on my team is by having a new hire cover 100% of support requests for 6 weeks. When they cover support, they meet business partners, build a picture of our existing portfolio, and sort through any access issues that crop up.

By the middle to end of this time, an obvious first project has usually come up. With appropriate direction and support, my recent new hires have been executing on projects within 6 weeks.

Key People to Meet

In this section I build a big list that takes about 3 - 6 months to work through. It’s customized to each associates’ role and prioritized by their key business relationships. Depending on the person’s role, I will ask the new hire to either meet or job shadow the person.

Potential Projects

The team helps me build up this list with good first projects. We want our new hire to get some wins early to build their confidence and get them engaged.

What works well

  • Personalizing the document to each new hire’s needs and experience

  • Providing a clear week by week road map

  • Most are happy to see a “menu” of projects they could work on

  • Maintain flexibility to adjust as things go on

What needs an upgrade

  • In practice, we stop using the doc once project work picks up

  • To fix this, I could use the onboarding doc as the 1:1 doc

  • It’s hard to keep all the different documents straight - new hires need one central landing place

Documentation

Good documentation is essential for a high functioning collaborative team. Our final doc new hires get is a living document which explains how our team creates and uses documentation.

Each team has to come up with its own norm for documentation - where you store it will be different from company to company and team to team.

In general, this document should cover all the bases and evolve over time to be as clear and helpful as possible.

Here are the guidelines for ours

  • If documentation is wrong or unclear stop what you are doing and fix it

  • If you don’t know how to fix the documentation, ask the team!

  • The folders are numbered and order by priority

  • Put the documents in the most logical place from the list below

  • All meeting notes and project files should be dated

  • Use YYYY/MM/DD as your date format so files order by date with the folders

  • The last guideline covers what documentation is for team members (internal) vs. externally facing (within the company)

Twitter avatar for @eswartz
Erika Swartz @eswartz
My team is reorganizing our collaborative documentation drive. The only topic with 100% agreement? Date things YYYY/MM/DD at the start of the file name so they sort.
Image
8:57 PM ∙ Oct 3, 2019

What works

  • I can find documentation where I expect it

  • This reduces everyone’s need to interrupt each other to ask for information

  • We built the content strategy collaboratively

What needs an upgrade

  • Keeping up good documentation is hard

  • Documentation can be confusing if there’s not enough context about when it applies

How will you know it’s working?

Onboarding is hard. Doing it well requires practice, feedback, and iteration.

My goals for onboarding a new team member are simple:

  • I want them to feel welcome and valued from day one

  • I want them to have help when they need it

  • I want them to have support and space to learn

  • I want them contribute to the team and our work in ways that feel meaningful and interesting to them

Do all that well, and value for your company and your team will follow naturally.

As a side note, this framework works for documenting your current job too. It’s especially helpful if you’re promoted internally to prevent questions related to your old job during your transition period. The access / skills list would stay the same, the onboarding journey doc would focus on in progress initiatives, and the documentation about documentation address how you’ve documented your own work.

Share this post

Improving On-Boarding

betterwithdata.substack.com
Comments
TopNewCommunity

No posts

Ready for more?

© 2023 Erika Pullum
Privacy ∙ Terms ∙ Collection notice
Start WritingGet the app
Substack is the home for great writing