TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Subject:FWD: Help! New Job, No Docs, Big Company From:"Eric J. Ray" <ejray -at- RAYCOMM -dot- COM> Date:Fri, 2 Oct 1998 09:28:48 -0600
Name withheld upon request. Please reply on list.
*************************************************
I just got a position as a senior tech writer for a new company
experiencing tremendous growth. Much of their growth was the result of
developers building some great software. You guessed it; there is no
documentation. If all of our developers were on a plane and it crashed,
so would the business. It looks like the developers would have to spend
a lot of valuable time with me so I could write the technical
documentation. I don't understand code, so they can't let me figure it
out for myself.
There is also no documentation on the business level. The accounting
process grew around these software applications. And the accountants
are new. No one really knows the whole process of the company here.
Anyone with experience dealing with accountants? They like different
flow charts, don't seem to know what they want, but want us to get more
involved in accounting than they want. It's intercultural
communications here: IT vs. Accounting.
I could drown in thinking about all the documentation needed here. But
what I need is an approach to tackle this: a business analyst approach?
People here are friendly and easy to talk to. I am slowly piecing
processes together. I was thinking of first outlining the processes and
instead of documenting, I could diagram the main processes. Any
suggestions on what kinds of diagrams, references? books?
When I went for the interview, I told my boss, "You've described ten
jobs here." This is a very open place, little structure. I like it,
but I don't want to spin my wheels, or reinvent one. There is one other
tech writer here who was pulled from the ranks of admin.
Any suggestions, thoughts, comments, jokes, anecdotes, advice would be
deeply appreciated.