I know, I know. It’s 2023. Can it be possible that there are still companies or large departments that don’t have a technical communications program? And I’m here to say, YES! there are. And it surprises me every time I go in as a contract technical writer to a larger corporation who thinks all they need are a few standard operating procedures. Or they have a couple of manuals they need to be updated only to find out they have no structure for their documentation. Or the structure they have is outdated or inadequate for their needs. Or it is so bureaucratized that it stifles innovation. It floors me really and sometimes it’s really sad.
As we in the field know at our core, a reliable organization is built upon accessible, up-to-date information.
So my point is, even in this day and age, you might need to help a company or an organization build a technical communication program from the ground up or help them to restructure a scattering of documentation into a well-organized program that they can manage effectively and efficiently. This is where you might get to put your consultant cap on and do some coaching. Warning! If they have not yet seen the light, and really don’t want to invest in functional technical communications program, you might need to take that cap off, update the document they hired you to update and leave.
However, if you are patient and can find someone in the organization who is frustrated enough with the “no program” approach to their documentation; and who is in a position to champion your “build a program” approach you might have found yourself a very creative ride. And to be honest it’s what I like to do best—create and build things.
If you weren’t expressly hired to build a technical communications program but you have discovered during the course of your contract that the company or department has a need, your influencing skills will be needed to enlighten them and likely sell them on the idea. How you approach this endeavor makes all the difference. And if you weren’t hired to build a program, you might not have asked for enough money and that’s another story.
There’s a very big difference between building a functioning technical communications program and updating a few documents. So there’s that. Trust me, I have fallen into that trap. I have placed myself in a position where I once signed a 6-month contract only to wake up one morning a number of years later still there at the same rate of pay. Companies (especially large ones with a complex bureaucracy for funding staff) don’t like to raise rates for contractors. And they aren’t very discerning when it comes to our value-added propositions. How does that happen? That’s for another blog.
When I talk about this, I’m coming from experience not theory. By that I mean I have built my career from the ground up without any degrees or certifications. I’ve just been doing the doing until one day, I went to a summit produced by the Society of Technical Communications upon the recommendation of a friend and realized, I had built myself a career. I also realized I was home — that there were other people like me. That there was a literal professional career path for me. And there was someone like JoAnn Hackos who could mentor me through her incredible book, Managing your Documentation Projects. It was a glorious feeling and a day of reckoning for me. I had a bonafide career path. This might sound strange to you, but it was none-the-less true.
Just to give you a little background. At the time, I was in my mid 30s and from a generation of women who without a degree were mostly placed in support roles. I was an administrative assistant who authored, edited and maintained a database of Material Safety Data Sheets. I also wrote technical specifications for newly developed chemicals that were roughed out by Chemical Engineers and Chemists. I had been doing this for four years as a routine part of my job. It was in that job that I learned to translate what I call “engineereze” into plain English that anyone could understand.
In that particular job, I was a sponge. I learned all about chemistry, oilfield services, systems and relational databases in addition to the importance of organization and workflows. This particular company (and industry) was very progressive with their use of computerization. I also kept a very detailed manual on everything I was doing and learning. So while I was likely severely underpaid for what I was doing, I look at it now as my college education. I just gained my knowledge of technical writing, document management and information design in the field rather than in a classroom.
So you’ve got your consultant cap on, there’s a recognized need, and you are being paid for the value you are going to add to that company. Now what? That depends. In my next blogs I’m going to talk about what the ideal program looks like, what it takes to sell it and how to build it.