That is be paid and then played as a technical writer.
Because the normal rules of project management and good manners simply do not apply as best addressed by the following three points…

1. Carrying out the role. That’s doable.I should know how to do my job but so many people are far more competent at writing than me (aside from their frequent spelling mistakes and poor grammar). But they will correct me though wrong and stand on their pride (or worse) should I disagree.
2. Defending the role. That shouldn’t happen under good leadership which should be supportive. Why? Because of problem number 3…
3. Explaining the role. Surely when one hires a person to a role they’d have an idea of what’s required. Nope not always. We’ll tell you the statement of work later…and even then unfortunately…In truth not many people know what a technical writer does. And sadly critically they don’t want to learn: they neither ask nor respond when asked.

Magic

Most people think we create documents by weaving gossamer out of nothing. We’re magicians. Which means many managers, stakeholder and subject matter experts see that unknown as a license to be ignorant, ill-mannered, incompetent, interfering or all four. I’ll leave what I’m really saying to your intuition.

What we need

Templates?

• For starters technical writers don’t need document templates. Yes it would be helpful to point us to that often undisclosed secret location. Otherwise we’ll beg, borrow or steal, or create one from another source, most probably more professionally than any existing.

Document Processes?

• And it would be nice to pass on how the organisation handles documents. So rare although so appreciated when communicated.

Onboarding

• Technical writers just stroll in, find a desk, open a laptop and start. One role I started by being dropped off cold at the client location by the project manager. For the next two weeks everyone I asked could help me get a laptop or an email or a phone. And without email, or phone details, I couldn’t contact the project manager, could I ? Until her boss, the program manager turned up, two weeks later and yelled at me. Needless to say even afterwards, she ignored me: to my face. And the project manager, almost no contact.

An Org Chart?

• And we don’t need an org chart. We already know who to ask. Still an up to date one helps. Otherwise, one gets circled back. A says ask B, B says ask C, C maintains A is the subject matter expert and A has just been reassigned. Or I end up in the wrong part of the organisation talking to someone with the same role but carrying out a different function. Quite surprising how any change projects actually take no account of the roles they affect: that’ll be taken care of in training…

And you are?

• And we don’t need an introduction. Again so rarely, I’ve been introduced to the people I’m meant to be working with. One would think that basic good manners would apply and in fact it more than helps. But the expectation is that we can rock up to someone we’ve never met and ask for their contribution as subject matter experts or stakeholder. And of course, they will cooperate fully and openly. Charm, persuasion and persistence helps but usually the look I get is who the hell are you and what the hell is this project? Of course as they’re the nominated subject matter expert (and have yet to be informed or enrolled), any refusal is project fatal.

Subject Matter Expert Shock

• Still something to cushion the shock of asking a non-nominated subject matter expert (SME) would help. In truth I’ve had SMEs and stakeholders ignore me, walk away from me, even publicly humiliate me (not the worst public humiliation I’ve had, sorry) and stand over me whilst being yelled at from point blank range. What do I do in those situations ? Act back in kind? Ignore them? How does one work with someone like that? What does that look like for them (and me) at home?

Test Environment

• And we don’t need a training environment, we can use the unstable testing one instead. And don’t tell us about any software changes, we’ll find that out ourselves. And adapt the documentation on the fly. Although writing documentation (and of course training) after the software has crashed can be challenging. And embarrassing too, especially when the users start calling you up post-live.

Can you get your people to get in touch with mine?

• And an escalation path would be most appreciated. Escalation is the last resort as there’s the possibility of jeopardising the subject matter expert, stakeholder or developer relationship. Although once invoked it means we become privy to finding out…well just about nothing. So many times I’ve escalated and either I’ve been ignored or if escalation does occur…no action has occurred (even after the subject matter expert yelled at me in an open office). You’re a technical writer is the implicit reply: you should know and you should accept it.

And a Project Plan

• And even so many projects, the training/technical writing isn’t included in the project plan: it’s assumed. Or it’s considered to be a “deliverable.” Nope it’s a project too. Usually that occurs with the phrase ,”that will be taken care of in training”, which usually is uttered one or two weeks before go live (and often when training has already commenced). And when I create a project plan as I do, guess what happens? It’s either ignored or as happened on one project utterly trashed. Who do I escalate to? The thrasher upper? And that didn’t work either.

So often, too often, normal rules of human engagement and leadership disappear when dealing with technical writers (and trainers). But there are exceptions…

What we really know…

Conversely, if you want to know if an organisation is collaborative and cooperative, ask the technical writer…