We also needed to set a clear time frame for how long the training period lasts.
At the start of this year, I worked with my Assistant Lead Developers to create an Internship Checklist, which outlines 20 specific tasks to complete. For each, we detailed the expectations and the learning goals.
Formal training should fit into the normal workload, never replace it. Spreading it out over a longer time period (perhaps a month) allows the training to organically fit into the employee’s new, regular responsibilities.
For example, some of our Internship Checklist assignments are…
Create five tasks on the task/bug tracker for your project.
Review someone else’s code using the pre-commit review tools.
Make three meaningful contributions (at least 5 sentences changed/added per contribution) to the company wiki.
In short, training should be standardized and organically integrated into ‘normal’ work.
Validate The Training
The First Two Weeks
the newcomer is invariably going through culture shock.
We have five very specific assignments to complete:
Read the Internship Introduction article.
Set up your development environment.
Read the Community Rules (since we have an open source community).
Read the official Standards.
Read and sign the wiki’s “Getting Started” page.
That first item is particulary notable. I created a tutorial that walks a new employee through the entire process of setting up and getting comfortable with their regular tools and workflow.
Throw ‘Em In The Deep End
Document Your Tools
To save time, and ensure everyone had access to the same knowledge of our tools and methods, I actually wrote documentation for our development network. No kidding: real prose documentation, hand-written in Sphinx, tracked in a repository, and published on our server. In it, I detail literally everything:
How to create and manage tasks,
How to submit code for review,
How to build from a repository,
How to set up a development environment from scratch on a computer,
How to use our IRC room bot,
I should mention that clearly documenting the tools leaves no excuse for employees not using them. Proper and regular use of development tools is a key component of successful collaboration. Make that expectation clear to every member of your team! Meanwhile, leave room for employees to give feedback on the tools and processes they’re using. Methodologies exist for the developers, not the other way around!
I’ve put a lot of time into our Development Documentation, and I know I’ll put a lot more time into it in the future. It’s worth the investment to have a canonical, up-to-date guide for every tool, every method, and every workflow in your company.
Wait For The Questions
I learned to give my interns the room to make their own mistakes, and for me to only get involved when asked. It is far easier for an employee to climb out of a hole THEY dug, rather than out of a hole YOU dug. If they mess up, graciously point out what they can learn from the situation, and encourage them to try again.
Conversely, when an employee does ask for help, respond to the call by teaching them how to solve the problem themselves. Share your own experiences, point them to documentation and existing code, but let them own the solution.
Summary
Create a formal training program that fits into and complements a normal work load.
Dedicate the first two weeks to initial acclimation - getting to know the team, becoming familiar with the tools, and exploring the company’s projects.
Give every employee the right to ask questions and seek out help from you and the rest of their co-workers.
After the first two weeks, don’t “ease” the newcomer into their job; drop them in the deep end with their new normal work load, and teach them to swim.
Maintain clear, friendly, and exhaustive written documentation for all of your company’s tools and common workflows.
Wait until employees ask you for help before stepping in (unless you have a managerial reason to get involved). Let them make their own mistakes.