What is one of the favourite old saws we pull out about being a Technical Communicator?

"I am an advocate for the user."

"I am user-focused."

"My voice is a sole cry in the wilderness of my corporation, like a clarion note leading the unaware in my company from darkness into light, and why won't they read my #@)(! first draft anyway?"

Well, if you are this advocate for the user, then I hate to say it, but you are also the one who has to take the arcane and strange languages of your fellow workers in your industry, the programmers and the business suits.

(As I write this, I am aware of a strong pro-software shop bias. So when I say programmer, think engineer or designer if you are in a manufacturing sector and need to be a user advocate, and I think it will generally apply.)

The first thing to realize is that, really, you are all very similar. You all want to keep your jobs. Usually keeping your job means selling your product and increasing sales of it. And you all love to solve problems. The problem being generally how to sell your product and increase sales of it so you can keep your jobs.

(See? All this time you didn't think there was much of a common ground between you and those other guys, and now I've pointed out there is a gigantic common ground, huge, bigger than walking around in Second Life even.)

Business analysts are often running on caffeine and the words from client meeting they are replaying in their mind as they get called in to look at a database issue with a different client.

In between this, they write requirements, sleep, and eat. Their problem is mainly to keep the client, who pays money to your company to get their problems solved, happy.

Usually to them, that doesn't translate as "Read my #@)(! first draft anyway".

However, you all approach the problem in different ways.

Programmers get business requirements, either well fleshed-out or drawn on a whiteboard as the business analyst has five minute before running to another client meeting, usually somewhere in the middle.

Their problem is to translate these business requirements into a new or existing product

a) without breaking the product, while

b) not veering an iota from those requirements because that's what they were told to do unless told otherwise.

Naturally, programmers tend to be more interested in fixing that bit of the product that isn't working and could cost them their job if they don't fix it. As opposed to reading your #@)(! first draft anyway.

So what to do?

As a Technical Communicator, you must be a renaissance person. A translator, a diplomat, a user advocate. But these users have to include your internal ones.

You need to try and understand where all the other guys are coming from. Without compromising the fact that you somehow need to make them understand where you are coming from.

If you do, you will have better documentation.

Because you will finally have someone read that first draft, anyway.

Any way it takes in your corporate culture.