Improving On-Boarding
Discover more from Better with Data
Improving On-Boarding
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.
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)
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.