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.

When was the last time you looked at the things you don’t do?

The reason I ask is that this very question is occupying my mind at the moment as I try to pull together both a content audit of what we have and a plan to create the things we don’t have. Which isn’t as easy as it may sound.

There are three or four different departments involved in the audit, and from each I’ve asked the same two things:

1. A list of all the content you currently have
2. A list of all the content you would like to have

With both lists in place, and understanding that some items in the first list may also need some rework or ongoing maintenance, we should all have a good view of what everyone else is doing and be able to plan a smarter way to produce more of the items in list two.

Whilst this is nothing radical it should help us by making people step back to see the big picture and allow us to move forward in one direction. Once this phase of the content audit is complete, the next stage, planning how to fill some of the “would like to have” gaps, will begin and once we start producing this content, regular catchups will help keep everyone up-to-speed and make sure we all focussed towards the same goals.

The tricky bit will be populating the second list. Asking your audience or colleagues for input will lead to one thing, a very big long list of “hey, do you know what would be REALLY good…” style requests. I’m more than happy to field those and they are, for the most part, good to have noted down.

Where it starts to get tricky is in the prioritisation of these things, and for that you’ll need to get some of the interested parties together to help. I’ve already covered how I do that but to make that process a bit slicker (it’s very ad-hoc at the moment) I’ll be setting up a common “Information Planning” meeting. That way we can involve the pertinent stakeholders in the decision process, and it will help communicate the ongoing plans around the Information Strategy.

Basically I’m trying to pull together a plan for the next 6-12 months that wraps up the ongoing development of the single source solution my team have in place (we are using Author-it), with the production of a knowledge centre (containing all of the product documentation, releases notes and more), which will be hosted on the developer community website I have setup, making sure we can provide partner friendly information all the while ensuring that we are covering all the levels of content required.

That, plus a few other side projects.

I have a mindmap of all this, and whilst I’m not fond of them it is allowing me to make sure I’m covering all the required areas.

The good thing is that it is all starting to come together so all I’m really doing is tweaking the timescales and goals a little to make sure they all align. The downside is that it’s generating even more work for me and my team which, as it happens, is actually a good thing.

So I’m currently casting my net far and wide to find a good way to keep a handle on this so that I’m always reasonably up to speed with where we are in the grand scheme of things. Forgive me if the following isn’t particularly well delivered, as I am thinking this through as I type it up.

First things first, we need a plan. Actually we need two. One is a high level map of the documentation structure for the entire product so we always have a view of what we are writing and where it will go, and the map will include indicators about the audience so we know who we are writing for at a given time.

Then we need to plan the next batch of work inline with the development teams, estimating what new content is need and how long it will take. Alongside that is the daily churn of small bug fixes and enhancements, some of which will need to be documented, and the supported streams of older versions of the product as well.

The occasional request via email rounds out the various routes in which new items of work are generated.

I’m ignoring, for now, passing comments by colleagues (most times I’ll just email them to our team email alias to make sure we’ve captured the request).

So, project plans, topic breakdowns, bug fixes and open requests for more information. Nothing to out of the ordinary I’m sure, nothing that each and every technical writer has to deal with.

Which begs the question, how DO you deal with it all? Over to you, how do you track your work?

Since my career seems to be following a path broadly similar to yours … I’d love to know what your experience was and any lessons learned.

Specifically Mark, who sent the email, asked a few questions:

1. How do you take over as manager for a group of technical writers?
2. How do you get better management buy-in (promise cheaper or faster docs?)?
3. What are the first activities you should do (content audit, benchmarking?)?
4. How soon is *not* too soon to start changing things?

I’ll break each question out into a new post, so without further ado, onto question #4.

How soon is *not* too soon to start changing things?
The compulsion to change or fix things that, from your point of view seem wrong or broken is natural. You wouldn’t be in the position you were in if you didn’t have that kind of mindset. However you must resist these initial urges!

A common suggestion, that I’ve seen elsewhere, is to wait at least 3-4 weeks before making any changes. That sounds like a sensible timeframe to me, providing that you use that time appropriately (see the rest of my posts in this series).

The first few weeks in any new job sets out your stall for the coming years. It can be very hard to change initial reactions so use the time wisely, tread carefully and make sure you set a level of expectation that you can manage. Communicate your ideas and thoughts, making sure to state that you are still getting to grips with things, make sure everyone knows that you MAY change things but that you are taking a measured and professional approach.

And, to be honest, that’s all I have to offer. Hopefully some of the things I’ve suggested over this series of posts is of some use. Many of them can be embellished and taken further, others might only be applicable in my own circumstance, but my belief is that as the manager of a technical communications team you are responsible for letting them do what they do best, whilst managing everything else around them. Technical Communications is still a widely misunderstood field, so a lot of your initial work will be educational, making sure everyone else in the company knows what your team has to offer, whilst proving you understand the restrictions and limitations within which they must work.

So, thanks to Mark for emailing me with the initial set of questions. If anyone else wants to chip in, the comments are open.