In my last post, I talked about the training plan for our new technical writers. As you would expect from someone who works on a knowledge base team, I documented the onboarding process to evaluate its success.
While my plan wasn’t a failure, it also wasn’t perfect. Here are some things we’ll remember for the next time we’re preparing to onboard.
You’re not alone.
There are better experts on your team, and chances are they’re happy to share what they know. Identify people who can take on some of the training. This gives new hires the best person to train on that topic, and gives everyone a chance to work with each other.
Be ready to deviate.
It’s probably been a long time since you were new on the job. A lot of what you do without thinking now was something you agonized over for hours when you first started. Ask for feedback often and get ready to change your training strategy to match the needs and curiosities of the new hires.
People want to get their hands dirty.
The piece of feedback I heard most while developing the onboarding plan was that writers wanted to start writing earlier. In this onboarding plan, I put writing assignments toward the end of week 2. This still wasn’t soon enough! The fact is, people feel unsettled in a new role until they’ve done work that somewhat represents what they’ll do day to day.
Next time, I’ll incorporate small wins throughout training—like “graded” assignments, quizzes, or smaller items to publish—that give new hires confidence in their roles from the start.
Everything is more difficult than you remember.
I made the big mistake of thinking the new writers could complete three assignments in three days. I based this on my level of productivity when I was a technical writer, which was eons ago in tech-industry time. The app was simpler and our standards for articles were different.
When it took much longer to complete the assignments, our new writers had intense feelings of imposter syndrome, which is already acute at the start of a new job. Be more reasonable about your expectations. Focus on the process. And, like I said above, incorporate small wins along the way.
In the end, most of this will be learned on the job.
Anyone who has ever worked a job knows this. Don’t waste your time teaching something that may not be used for weeks. Wait for when it is immediately applicable to lessen the cognitive load on your trainees to imagine a world where they’ll do what you’re showing them.
You know less than you think.
Training someone is a good way to remind yourself that you’ll never know everything about the position at which you’re an alleged expert. You’ll forget to get the right access to something, you’ll have to stall as you try to find the right company policy information, or you won’t remember the right style guideline. Don’t sweat it! Document these lessons so you’re more prepared for next time.
You’ll forget something.
The smartest part of my plan was building in a squishy third week for extra training time. Initially, I thought this would be for the writers to mess around on parts of the app they were interested in. Instead, it was filled with completing assignments I didn’t build in enough time to do, and training on our CMS, which I completely forgot about.
In an industry that changes so fast, you learn that few things are ever set it and forget it. The best training plan is flexible and allows you to easily slot in forgotten or underrepresented topics.
While every organization requires a different plan, the mistakes I made were human ones that can apply to training across many disciplines. So, learn from me! And remember that sometimes the best people to create a training plan are the new hires in front of you.