OT: Providing quality documentation when in startup mode

[Syed Zaeem Hosain (Syed.Hosain@aeris.net)]

Please pardon my off-topic (i.e., to FrameMaker) response here. But, I wouldn't mind hearing from others on my comments below - feel free to keep it off-line to me if you want.

Robert Lauriston wrote:
> Typically, we are overhead, and startups need to focus on selling something first.

Yes, my company was not totally immune either.  But, as a founder of the company, I made sure that the quality of our documentation was deemed important right from the start.

For a few, very simple, reasons: 

	(a) achieving those early sales can require good documentation for our customers.
	(b) internal engineering specs have to accurately match what we want to develop and deploy.
	(c) internal process docs (for our employees) need accuracy to ensure good support.

Because, fundamentally, I have always believed that the *quality* of documentation, particularly external technical stuff, is a reflection on the quality of the *rest* of the company. If we don't get our external technical docs right, then that same poor quality attitude could also match poor internal processes and reflect badly on our people.

The last thing we want to do is raise any doubts - even subconscious ones - in the mind of a customer seeking the kind of services we provide.

So, while I am not a tech writer by training or profession, I made sure that our documentation was as good as I could get it to be, till we got our first tech writer hired. 

My writing objectives (for technical documents, API's, etc.) are quite simple really:

	(a) Thoroughly reviewed accuracy in the content (issues would lead to customers wasting time correcting their code that connected to our APIs).
	(b) Anal consistency in the look-and-feel ... everywhere! Title, logo, paragraph spacing and indentation, tables, etc. (this is what leads to intuitive *quality* measures in readers).
	(c) Spell-checked thoroughly (nothing speaks more to poor quality than spelling and grammar mistakes ... just like in resumes!)
	(d) No ambiguity in reading a specification - multiple interpretations can lead to wasting time.
	(e) Relatively frequent edits to fix any errors - I often released new versions whose sole purpose was to fix typographical errors. Accuracy fixes were always urgent.

FWIW, with about 90 people in the company, we have two writers - one is in Marketing and one in Engineering. The writer in Marketing does Marketing collateral, does white-papers (using my technical drafts to begin from) and writes for our blog, etc. The writer in Engineering does technical spec documents for customers. 

And, one more part-time writer in our Operations team. Works tech support for customers/networks after-hours when life is generally quiet,and thus has the time to write/update our internal process documents. Her work is reviewed by her peers in the department. Accuracy is far more important in these docs than look-and-feel or grammar. So, if some *fact* is wrong (rarely!), she will get relatively quick feedback from those users/peers! :)

Z