How Should I Handle Being Asked to Rewrite Company Documentation?

[confusedeng]

One of the founding principals of our company approached me last week asking me to come have a chat with him in his office. (I had never had any interaction with him before this point) Anyways, he explained how he needed someone to rewrite the documentation for one of our manuals and asked whether or not I would be interested in doing so, and being a newer employee in the heat of the moment I said yes.

However, the reality is that I am not the least bit interested in rewriting a couple hundred pages of boring documentation, and that I would much rather spend my time learning new technical concepts, solve complex technical problems, write technical papers and develop sample cases.

The founding principal who had approached is not my direct supervisor, and said he would need to coordinate with my direct supervisor so that I could allocate time for rewriting the documentation.

Today my supervisor approached me regarding the matter, and I expressed how I was unsure whether or not I wanted to participate in rewriting the documentation, and that I would rather be tasked with more challenging and interesting tasks where I get the chance to learn and figure things out. This was not at all what I had expressed to the founding principal a week earlier.

As of right now I am unsure where I stand, and whether or not I will be stuck with the tedious task of rewriting one of manuals.

What should I do? Should I talk to my supervisor again? Should I go speak with the founding principal again and explain how I've had second thoughts and changed my mind? Should I wait until the founding principal approaches me again?

Thanks for any comments/suggestions/advice you have for me!

 

[berkeman]

One of the founding principals of our company approached me last week asking me to come have a chat with him in his office. (I had never had any interaction with him before this point) Anyways, he explained how he needed someone to rewrite the documentation for one of our manuals and asked whether or not I would be interested in doing so, and being a newer employee in the heat of the moment I said yes.

However, the reality is that I am not the least bit interested in rewriting a couple hundred pages of boring documentation, and that I would much rather spend my time learning new technical concepts, solve complex technical problems, write technical papers and develop sample cases.

The founding principal who had approached is not my direct supervisor, and said he would need to coordinate with my direct supervisor so that I could allocate time for rewriting the documentation.

Today my supervisor approached me regarding the matter, and I expressed how I was unsure whether or not I wanted to participate in rewriting the documentation, and that I would rather be tasked with more challenging and interesting tasks where I get the chance to learn and figure things out. This was not at all what I had expressed to the founding principal a week earlier.

As of right now I am unsure where I stand, and whether or not I will be stuck with the tedious task of rewriting one of manuals.

What should I do? Should I talk to my supervisor again? Should I go speak with the founding principal again and explain how I've had second thoughts and changed my mind? Should I wait until the founding principal approaches me again?

Thanks for any comments/suggestions/advice you have for me!

Can you say what the product is (in general terms)? I have worked with some technical writers that did an outstanding job of taking technical/engineering concepts and turning them into understandable, very helpful documentation. They were even able to work with the hardware, write software examples, and generally offload me from having to support them very much at all.

It sounds like if you can turn that "boring" documentation into very useful, modern documentation, that it could be a good item on your performance evaluation for this year. You can make it clear to your supervisor that you don't want to be a technical writer as a profession, but that you think you can bring a good technical perspective to this task, and are willing to do your best on it.

Even though I'm an R&D engineer, I've also done work in Technical Support, Documentation, Manufacturing Test Development, and a lot of other peripheral tasks. It's not a bad thing to broaden your skills, IMO, as long as you keep your main technical interests in mind.

 

[confusedeng]

Can you say what the product is (in general terms)? I have worked with some technical writers that did an outstanding job of taking technical/engineering concepts and turning them into understandable, very helpful documentation. They were even able to work with the hardware, write software examples, and generally offload me from having to support them very much at all.

It sounds like if you can turn that "boring" documentation into very useful, modern documentation, that it could be a good item on your performance evaluation for this year.

I am confident that I have the ability to do what you've described above, but I am worried I won't enjoy it and that I will be stuck doing something I don't enjoy for a long peroid of time. I am also worried as to whether I would be learning less by writing documentation than I would otherwise by doing other work.

You can make it clear to your supervisor that you don't want to be a technical writer as a profession, but that you think you can bring a good technical perspective to this task, and are willing to do your best on it.

How should I go about doing this? Should I approach my supervisor first thing tomorrow? Should I wait until I am approached?

 

[Choppy]

Sometimes when the company bigwig comes down and asks if you're interested in doing something, it's just a polite way of tasking you with that job.

Whether you're actually interested in the task only becomes a factor when management is in a position to play to employee's strengths and passions. At the end of the day, it's a task that needs to get done though and if management doesn't have any volunteers, they have to appoint someone.

Because you've agreed to do it, I would avoid waffling on it. Take it. Do a great job. And let your supervisor know that you're interests lie elsewhere.

 

[AlephZero]

I would suggest you try to get a look at the old manual and make your own estimate of how long it will take to do the job before you start negotiating. At one extreme it might be a "reformat the document so it doesn't look like it was written 20 years ago" task, which might not take long if the content is all digital and you have some of natural aptitude for it. On the other hand if you need to take it apart word by word and update the information, you are going to meet more than enough "learning new technical concepts" and "solving complex technical problems" along the way. You will also probably learn a lot about the product, and about how the company really works, and who really knows what they are talking about (which might not match the organization chart!)

If it is an in-depth rewrite, it probably won't be a full-time job anyway, because you will inevitably be waiting for other people to supply information that might not be part of their "normal workload" either.

The interesting "people-watching" question is "why you". If this really is an important task for the company, it seems a bit strange to give it to the new kid on the block. On the other hand if it's some kind of "initiation rite" for new employees, just do it competently and then get on with the rest of your life.

 

[analogdesign]

The best way to really learn technical concepts is to document them. Your ability to clearly and succinctly capture the essence of the product and whatever concepts are needed to apply it successfully.

I am a design engineer and it is very common in the semiconductor business for the designer to draft the datasheet. I typically write the datasheet before I've finished the design. You'd be amazed at how many misunderstandings and mistakes I clarify doing this... and I'm the designer! Imagine how much better you'll understand your company's products when you've documented them!