Next week the first of two new recruits joins our team. Both are graduates and whilst neither graduated from a Technical Writing based course they both have a good mix of skills, coming to the position through different routes. It’ll be a challenge for them, and a challenge for us, to integrate them to the team smoothly and successfully. I’m sure they will both do well, but to give them the best chance I’m preparing a few weeks of training for them, in various aspects of the job.
I’m trying to anticipate what they need to know, and when they need to know it, and whilst I’m very wary of letting my own experience get in the way it does mirror what they will be going through as my route into this profession was via an Electronic Engineering course, and I too had no experience in Technical Writing.
Training on our authoring tool (Author-it) is straightforward enough, and we will be mentoring each of the recruits as well so day to day questions we can handle.
We will likely use the IBM book “Developing Quality Technical Information” to provide a grounding in the basics of Technical Writing, along with an eLearning book titled Basics of Technical Writing that we purchased from CherryLeaf a few years ago.
They will have to learn how we do things, our specific processes, and learn how the overall Development team works so they understand where they fit, and they will receive a series of training exercises to complete before they take our product training course. On top of all that they will have a week long company Induction.
I’m a great believer in people learning by doing, so I’m planning a set of small tasks which will be checked and reviewed, and which will ultimately find their way into our documentation set.
Beyond that, I’ll be looking for them to ask questions, try things, make mistakes and learn from them, and then ask more questions. This industry is too varied to try and learn everything at once, and ultimately it’s down to them to decide what areas they want to push into… user experience? content design? API information? Who knows.
I do know it’s a challenge, for everyone involved, and that’s one of the things we, as a company, do best. There is a saying we have about being two feet outside your comfort zone, that’s where you learn best, that’s where you grow and start to understand your capabilities, so we will see how our recruits get on!
For me it’s doubly exciting as this is only the second time I’ve taken on graduates. I learned a lot the last time, both about how to train them and about my own foibles and attitudes to my profession so I’m brushing up my own knowledge to make sure I, and the rest of the team, give them the best change they have. In saying that, the first time I did this I was in my first ‘senior’ position, that was 10 years ago so hopefully by now I’ve gained a little bit more experience!
After all, you learn something new every day.
Have you brought a graduate into your team? Or are you involved in training or mentoring new recruits? If you have any suggestions I’d love to hear them.
New recruits always spur me to write up more of those de facto procedures that always develop. The best thing about new people is that they are ideally placed to see the gaps in your process (or logic). I’ve always thought the trick is to sit them down after they’ve been there long enough to understand what is going on, but no so long that it feels ‘normal’ yet, and ask them what doesn’t make sense. I still remember my first job, how many things were done (and in a particular way) just because they always had been…
For the first project, I always try to find a well-defined and well-contained task that they can see the boundaries of. Much more rewarding.
Hey Sarah,
That’s a great idea. We did something similar with the last person that joined our team (who has experience as a technical writer), asked her to keep a note of things that didn’t seem ‘right’.
I will schedule something similar with our new starts as I’m sure they will have many more questions given that they are both graduates.
What a coincidence! We just recruited two new joinees in our Technical Communication Team today and I am partly responsible for helping them settle down and learn the work and processes here. They too are new to Technical Writing and we are all exited as to how we help them gel in our team.
I like the part where you expect a lot of questions. For that, I believe the most important is to create an open atmosphere where they feel free to ask question, make mistakes and grow out of them.
I also like your idea of giving them some writing exercises and verifying them against our standards. Will put that into practice here and see how it is reflected.
Like they say – Teaching once is learning twice. So I am really exited to see how this turns up.
Thanks Gordon. FYI We’ve retired our Basics of Technical Writing self-study course, replacing it with “Technical author basic/induction training course” The link is http://www.cherryleaf.com/training_technical_author_basics.
The new course is a series of live interactive webinars, covering more content than the previous course. There does seem to be a trend towards recruiting graduates and training in them up, leading to a few companies asking if we had a course suitable to that type of person.
Ellis
Good tip on keeping a diary of what didn’t seem right.
I remember the feeling of fear on my first day as a fresh faced graduate. I never got taught how to do my job, I just got thrown in at the deep end and learned quickly. That worked well for me, as I could quickly learn what worked and what didn’t. The most important thing for me, was having the freedom to try out my own ideas. The thing is, I didn’t realise I was allowed to try them out at first, until my boss told me to stop suggesting ideas all the time and just do them instead!
Nice post Gordon, thanks for sharing.
Nice post Gordon. We had a graduate start this week. Like you I have a belief in giving them to basics and leaving them to learn from their own mistakes. It is how I learnt. Once he feels comfortable with the tools, he has the task of writing one small area of our help file. It has already been written, but we want him to write it as if it hasn’t. He has expertise in this area so knowledge should not be an issue. I’ll mentor him as he goes along but we are interested in seeing what he comes up with. Maybe he’ll come up with a better way of structuring, wording, etc.