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.

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.

You know when you have a set of disparate, yet related, ideas and plans and whilst you know they WILL all tie together it can sometimes be a struggle to both see how that will happen and communicate it to your various stakeholders? Well that’s where my head has been the past couple of weeks. No wonder I’ve been tired and headachey, my brain hurts!

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.

Like most technical writing teams we are small in number. As such, monitoring and tracking both the work that needs done as well as the work that is in progress can be a challenge.

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?

I recently received an email which asked:

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.

I recently received an email which asked:

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 #3.

What are the first activities you should do (content audit, benchmarking?)?
First things first, make yourself a coffee. In all seriousness, fitting into the culture of your office and colleagues is crucial, and one of the best places to get a handle on that is the approach to coffee/drinks breaks.

Then all you need to worry about is understanding the process that your company and team follow. Are you based in a waterfall type system? Are you Agile? And regardless of the underlying methodologies, how do things actually happen? Simple, right? Well it can take a little investigation but it certainly shouldn’t be difficult.

Briefly I’d tackle things in the following order:

1. Talk to the members of your team
2. Talk to the people who set the expectations for your team
3. Audit your content (high level for now)
4. Manage expectations

If you are joining an existing team of writers, then I’d suggest that the one of the first activites should be to sit down with them, one by one, and try and understand how they work, what issues they are facing and what expectations they have of you, and of their colleagues on a day to day basis. From this you should get an understanding of their process, how they go about creating the information, how editorial and technical reviews are handled, and how that information is published. Collate all of the responses, you’ll revisit them later, although I would take any personal or specific issues to one side and deal with them accordingly.

Next up I’d get a handle on the expectations being set on your team, which will include talking to other departments, and a good understanding of why that expectation is in place. There is a chance that there are unknown expectations on your team so make sure you understand what they are and if they are valid.

Then I would certainly tackle a high-level content audit. Understanding the content you have and learning what the audience of that content requires goes a long way to helping you understand the working practises and decisions made in the past. It should allow you to see if writing style guides are being followed, and whether an editorial review process is working. It won’t help with the technical review phase though but there are things you can do in that respect as well.

To me, a high-level content audit asks the big questions, why does the document exist? Why is the content of the document structured the way it is? Look at the content

So far you’ve talked to the people in your team who create the content, you’ve understood the expectations they have and the expectations on them. You know what type of content is being produced, why it exists, and have a good idea of what it contains and how it is produced.

Now the tricky bit.

Does the process that the rest of the company thinks you are following (their expectations) match up with the process your team is following? If it does then great. If it doesn’t then this is the first thing you need to address with your team.

Rather than try and fix things yourself, get your team together in a room and tell them what you’ve discovered. This is not an exercise in ‘why aren’t you…. ‘ this is the beginning of a collaborative venture, so make sure you pitch it accordingly. What you need to get from your team is the real reasons why the expectations don’t match. From their side it may be that they were unaware of some of those external expectations, or it may be that whilst the expectation is valid the team haven’t been able to progress that part of the process as they would like.

Once you have completed that exercise, and understand the position of your team and (and this is important) your TEAM has a common and understood position and process, you can then revisit the expectations being placed on your team. It may ultimately mean you need one meeting with representatives of both your team and those from the other areas of the company, but this will allow everyone to understand any issues, resolve them and move forward with a process that everyone understands.

Everything else to that is largely secondary. Yes using the right tools makes a difference, yes better knowledge of your audience is crucial, yes there may be improvements to specific areas of the content that could be made but all of those should start to filter to the top of your pile naturally. However, if the expectations both on your team and from your team are not manageable then you are only setting yourself up for a lot more pain in the future.

I recently received an email which asked:

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 #2.

How do you get better management buy-in (promise cheaper or faster docs?)?
Management buy-in is key to any team within an organisation. If the management don’t properly understand what the team brings to the organisation, be they hard or soft benefits, then your job will remain a battle.

So, how do you get it?

Firstly I’d suggest not making any promises to do things cheaper or faster. Whilst it is largely the type of thing your boss will want to hear and they are promises you can make later on, the first thing you need to quantify is whether you are producing what is needed or not. That may mean looking at improving the quality of the documentation, or it may mean re-evaluating the type of information that is produced.

How do you do this? Talk to your audience.

A simple statement, and something it everyone will tell you is core to your ability as a technical communicator but which remains one of those things that is very hard. Even if you have direct access to your audience, the customers of your part of the product, it can still be tricky to get useful feedback from them. With that in mind I’d set up a series of one-to-one interviews. They don’t have to be long, nor do they have to be formal (in fact I staged mine over a few casual chats, grabbing 15 minutes of time from some of our SMEs over the space of a couple of weeks) but you must talk to them.

The benefits are two-fold. Firstly it raises the profile of your team and alerts your customers that you are actively engaged and trying to improve things, secondly it should mean you can formulate a plan to take to your boss.

The former should also start to generate some goodwill, you’d be surprised how many people understand the need for good documentation and you may well be able to garner some support from some other parts of your company. Don’t be afraid to ask people to email you and your boss with their thoughts of your new plan, the more evidence she/he sees that you are driving improvements yourself, the more likely he will be to back you.

But ultimately you need, at some point, to present a plan to your boss. One that outlines what you are planning to do, what the benefits are, and how long you think it will take to achieve.

Benefits should be stated in business terms – for most software documentation the main cost benefit is to reduce the time it takes your audience to complete a task using the software – and the more specific you can be the better. Essentially you have to justify why the company is spending money on you and your team, and ultimately you may be asked for a fine grain of detail that you just don’t have. So, if your plan is to reduce Support calls, make sure you have a way of monitoring the stats AND that you can attribute them to the documentation, before suggesting that as a plan!

Buy-in, in my experience, is largely gained by showing a business awareness. Ever boss will want things faster and cheaper but instead of make presumptions, involve your boss in those discussions. During the start of a project, take the initial scope of the documentation that you and your team have planned, prioritise it (using MoSCoW perhaps?) and take that to your boss. Then it’s a simple case of saying “OK, this is what we MUST have in the documentation, this is what we SHOULD have, these are the things we COULD have and there are also some things we WOULD want to have, can you help me narrow this list down as we can’t produce it all”.

That allows your boss, in conversation with you, to make sensible decisions around the production of the documentation, allows a decision on faster or cheaper to be made, and shows that you understand the business reasoning behind what you do.

Be prepared to have discussions where you lose, where that Quick Start guide that you think is a really good idea gets put to one side. Part of gaining the trust of your boss, and his/her buy-in to your plans is showing that you have the bigger picture in mind, and if you can prove that then your boss should happily back you all the way.