Hiring new staff is fraught, and rightly so, as it’s likely to be the biggest ‘purchase’ you make for your company. I’ve conducted enough interviews that I’m fairly comfortable with the process, and have a good feel for when to press for more information and when to sit back and let the candidate sell themselves.
I may post more on how I conduct interviews later (anyone interested?) but as I am hiring right now I’ve started to think about the whole induction process, and how we can best get a new technical writer into the team and up to speed.
First of all there is the timing of these things. Rarely do you get the luxury of being able to streamline a new team member into the start of a release lifecycle, so you need to consider what they will be working and, possibly, whether you keep them out of the main stream of work until a new cycle begins. Like most departments we have a slew of ongoing tasks that are not directly related to new product development, and one of my favourite items to get a new start to tackle is the installation guide.
Typically, unless you are writing documentation for a very simple application, the initial setup and configuration of a product can be confusing. You may need to consider underlying platform choices, supporting applications, databases, connection protocols and so on, all of which the customer controls and which mean there isn’t often a common set of instructions.
There may be some initial configuration required before you can run the setup routine, and the choices made available may then impact what options are available later on in the process.
Ultimately it’s the trickiest thing to get right so my view is that a fresh set of eyes, belonging to someone who has yet to be inflicted with the curse of knowledge (that is, they don’t know anything about the product so don’t presume the audience will either), is ideal for reviewing and updating an installation guide.
Beyond that there are matters of tooling and procedures to be learned, as well as the general culture to be communicated and encouraged. I firmly believe the latter is the more important, tools and procedures can be learned over time, but fitting someone into an established culture, into the way we think and the way we tackle our work is far more important.
Huh – how appropriate: I’ve signed on with a new employer and just started this month, so I can totally relate! So my comments are sort of from a subject’s point of view – albeit, a somewhat reflective one, I would hope… 😉
In my current company, I’ve just completed three weeks of very thorough training – even if it merely scratched the surface of our rather complex product. So it didn’t give me all required expertise, but certainly the confidence to jump right into the current development lifecycle and start to pull my load. And I look forward to it more than to a typical beginner’s task which often smacks of a semi-popular, semi-important job such as updating screenshots.
I second your point about corporate culture, though I find it a bit difficult to convey, because setting examples speaks louder than just talking about it.
– And yes, I’d be very interested to hear about yout interview process, esp. about what you found worked well and what didn’t.
It’s a great strategy for a new hire. How do you make it clear to the newbie that there is real benefit in their ignorance, rather than them perhaps interpreting this task as a kind of fraternity hazing ritual? It could be quite stressful for them, do you do anything specifically to counteract that?
I too would be interested in reading about your interview strategies.
catherine – by the nature of the fact I’ve hired them, I’d be confident that they’d understand why revamping the installation guide is an ideal task for them.
Ideally it would be a no-holds barred exercise as well, with all options on the table.
Fraught with what? Joy? Difficulties? Interest? Questions?
Bill – yes, all of the above, I was just trying to convey that it’s a stressful thing to go through, for a large variety of differing reasons.