Re: It's a new millennium. Will companies ever learn?

["Chuck Martin" <twriter -at- sonic -dot- net>]

Grrr...the one thing that annoys me all to heck about Outlook Express,
otherwise a decent newsreader, is that it sporadically crashes when I insert
a signature--after I've spent time and effort composing a reply--and I
almost always give up on replying for a few days. Thus the tardiness here.

"Andrew Plato" <intrepid_es -at- yahoo -dot- com> wrote in message
news:85241 -at- techwr-l -dot-  -dot-  -dot- 
>
> "Chuck Martin" ...
> >
> > A chunk of a job posting today on craigslist:
> >
> > "...seeking a
> > talented Technical Writer to work on a cutting-edge E-Business project
on a
> > two- to three-week contract basis. The
> > Technical Writer will create a user manual for a custom written web
> > application. Documentation will include graphics, screen
> > shots, and flow carts. Duties include interviewing developers and users
as
> > well as compiling and formatting existing
>
> > documents. "

> >
> > Now putting aside the content and organization of "existing documents"
> > probably aren't anything close to ready for users, this means doing a
manual
> > form scratch in 2-3 weeks.
>
> A skilled, experienced contractor could do this in 3 weeks. It would be a
busy
> 3 weeks, but it is possible. Without knowing the details of the project
you
> can't assume this can't be done in 3 weeks.

A 24/7 3 weeks, maybe. And if I was not already committed to another
contract, I might have even attempted it. And charged good $$$ (although
there probably would have been hungry writers who would offer to do it for
less). But why, after probably weeks and months of programming, should a
good technical writer suffer through the agony of such a compressed
schedule, putting out a less than polished product, because of the company's
either ignorance or tightwadness?

>
> > Even in this allegedly enlightened age, technical
> > communicators still are not part of the development process, but rather
> > brought in at the end, when the product is nearly complete.
>
> There are good reasons to sometimes leave writers out until the end.  1)
Save
> money, 2) Save time.  What will the writer do while they are developing
the
> project? You can't write docs to something that doesn't exist.  Sure it is
nice
> to be around during those phases to watch the process, but most writers
just
> jerk around doing wasteful one-off work waiting for the developers to
finish
> the product.

I am sorry to hear that you have had such bad experiences with writers. Most
of the writers I know keep quite busy through most of the phases of
development. But then, programmers aren't always writing code; they too must
prepare and plan.

>
> The conventional wisdom that all writers must be standing around from the
> moment a project begins just don't hold all the time. When money is tight,
such
> luxuries are abandoned. There is also no reason to have a writer wasting
time
> and money on plans when such work can be done quickly at the end.

And shoddily--no matter how good the writer. Why wouldnpt the same be asked
of a programmer: the specs are all writeen, and you can write 100 lines of
code a day, so here's 30 days to write the 3000 lines of code needed. It's
no more about cranking out English words that it is about cranking out C++
code.

>
> > A lot of these
> > new companies are being run by people who used to be at previous
companies,
> > in some cases, several companies. Aren't these people learning anything?
> >
> > And who is going to have time to find and schedule time to interview
users
> > in 3 weeks?

>
> Many smaller companies simply do not think it is important to have
technical
> writers around from the beginning of a project.  I believe this attitude
comes
> from two sources:
>
> 1. Lack of money.
> 2. Experience with bad tech writers.
>
> There is a LOT of bitterness out there toward tech writers. Many
engineers,
> CTOs, and upper managers think writers are a waste of money. And honestly,
a
> lot of writers ARE a waste of money because they don't write anything.
They sit
> around fussing and obsessing over fonts and gerunds demanding processes
nobody
> wants and procedures nobody will follow.

Not most of the technical writers I've worked with.

>
> We just started working with a technology firm in Silicon Valley. The CTO
> recently left a very large company.  He made it clear to me from the
get-go
> that if any of the writers failed to write documents he would fire them on
the
> spot. I am paraphrasing, but he told me numerous stories of writers he
hired
> who argued all day over fonts, build detailed plans they never followed,
> complained again and again that they couldn't do their jobs.  Basically,
he was
> sick and tired of people calling themselves writers when they didn't want
to
> write anything.

I wonder what he would do if he walked by a programmer's desk and saw him or
her updating a project plan instead of writing code? The programmer wasn't
writing code, so would he fire the programmer on the spot? If notm then I
see a definite--and unreasonable--double standard.

>
> > At what pooint does it sink in that maybe it's no longer a matter of us
not
> > fully educating the powers that be as to the value we do bring during
the
> > whole process, but simply a matter of (a) simply stupid people still
running
> > the shows not knowing what a fully staffed team needs, or (b) stupidly
> > frugal people running the processes who aren't willing to fully staff
teams
> > from the start?
>
> I think this is a simple issue of value-add.  Many writers fail to
consistently
> prove their value to the team.  They fail to show how they can directly
help
> the process of producing products and technologies.

What about the ones who do show it, but their talents are consistently
ignored by the people who that information is being comunicated to. At my
current project, I showed the person who is my manager here how I can do
more than write, how I can be involved in design, usability, and much more.
Yet in later meetings, he referred to my role in this project as
"copywriting."

>
> A lot of people still haven't learned that results speak much louder than
> plans.  Nobody cares if you have a great plan. The results are what
matter. If
> you cannot produce results, your a waste. A good writer is resourceful and
can
> produce quality results in a less than ideal situation.
>
> However, most writers in less than ideal environments throw up their hands
and
> bitch endlessly about how the world doesn't understand their needs. Boo
hoo,
> tell it to the unemployment office.
>
> This attitude is summed up in the fact that many writers take months and
years
> to write documents that could easily be done in days or weeks. If you cut
off
> all the unnecessary planning and just sit down and jam out the docs, you
can
> get a lot done.

Many writers do exactly that--and turn out crappy documents. Just as
programmers sit down and start wrtiting code and turn out unusable software.
There is little difference between the steps needed--both in planning, in
production, and in testing--in turning out both quality documents and
quality code. Yet when programmers are involved in the activities that are
one-off from actual writing, no one says anything, but when writers are
doing the same thing, they are accused of wasting time.

>
> I don't think this is an issue of "when Will companies ever learn", I
think
> this is an issue of "when will the tech writers ever learn?"
>
Some years back I began work at a small company, and shortly afterward bagan
attending the weekly project meetings of the products I was writing about.
At first, the project manager questioned my mere presence. After a period of
time where I mainly listened and absorbed, I began making contributions.
Then began an attitude of ther couldn't be such meeting without me being
there, the writer being an important part of the whole team. A year later, I
was asked by that very same manager to design (the UI and workflow) of a
Windows utility that would duplicate the functionality of an existing Mac
utility.

Good technical communicators do a lot more than "copywrite." And they
contribute throughout the product development cycle, even if words aren't
actually being put to paper. Many people with those capabilities (as opposed
to the font fiddlers you seem to too-often encounter) have shown this time
and time again, to executive and ptoject managers who move from company to
company. Yet these lessons still aren't learned, and technical writers are
still too often saved for last.

--
"[Programmers] cannot successfully be asked to design for users
because...inevitably, they will make judgments based on the
difficulty of coding and not on the user's real needs."
        - Alan Cooper
        "About Face: The Essentials of User Interface Design"

Chuck Martin
twriter "at" sonic "dot" net      www.writeforyou.com



^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Develop HTML-based Help with Macromedia Dreamweaver! (STC Discount.)
**NEW DATE/LOCATION!** January 16-17, 2001, New York, NY.
http://www.weisner.com/training/dreamweaver_help.htm or 800-646-9989.

Sponsored by DigiPub Solutions Corp, producers of PDF 2001 
Conference East, June 4-5, Baltimore/Washington D.C. area.
http://www.pdfconference.com or toll-free 877/278-2131. 

---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot-  Visit 
http://www.raycomm.com/techwhirl/ for more resources and info.