Technical Writer

It’s my job to document the system.  Most times that works fairly well, but every once in a while you come across someone who’s determined to do it all himself.

I’m working with one of those at the moment.  He has a major piece of knowledge he needs to transfer to others in the team.  He wants to do it all.

No matter that it’s my job, that all I do all day is write about the system. No matter that he has to do other things, like coding, 40 hours a week (except for the bit where he’s supposed to hand over knowledge to me so that I can write it up for him).  No matter that he’s flat out on projects that must be completed for the next software release. No, he insists on doing everything.  Setting up a training course, writing the material, running the demos.

Worse, he’s not even doing it in the standard format I have already set up for knowledge transfer.

This guy has some really good ideas.  I like what he’s trying to achieve.  However, I can’t just sit back and let him do it.

First of all, I’m fairly sure it’s not going to happen.  He has a full schedule even without this work and we tech writers know from experience that the first thing to fall by the wayside when a release is behind schedule is the documentation.

Secondly, there is no need for him to do it.  He has a perfectly good resource—me—sitting there waiting to do it for him.  All he needs to do is spent a tenth of the time he otherwise would, transferring the knowledge.

Lastly, I can’t let him do it because we can’t afford to let everyone loose with their own way of doing things.  We already have a process for doing and presenting technical documentation.  It may not be the best, but it is consistent.  We don’t want people to learn a whole new system.  We want them to use the one they are familiar with.

There is only one way to deal with people like this.  Carefully.

You need to keep them on side and working with you, but you also have to somehow wrest control of the project away from them and get them to accept that you own it, and that they are doing it your way—or rather, the same way everything else is done.

Take on board their ideas, by all means.  Do some future planning with the really good ideas and try to fit them in to the overall training/knowledge strategy if you can, but don’t let them do their thing.

That’s a lot easier said than done.

Last Modified : September 4th, 2007
Filed under : Tech Writer, Knowledge Base
Navigate : Previous post / Next post