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:Re: Process, not bureaucracy From:SteveFJong -at- aol -dot- com To:techwr-l -at- lists -dot- raycomm -dot- com Date:Mon, 6 Sep 1999 10:56:18 EDT
Cam Whetstone <camw -at- rocketmail -dot- com> responded to this statement of mine--
> From my perspective as a manager, process helps me ensure that when
> someone does good work, everyone can learn to do as well. It also
> means if I know what works, I can ensure everyone does it.
--with the following--
> The down side of this, Steve, is that what works well for some is not
> the same as what works well for me.
Cam, I think we're talking very much at cross purposes here--but the
difference is appropriate for a topic called "process, not bureaucracy."
Let's compare your example with something I had in mind.
Your example of something that works well only for some people is hours: you
want to come in early, someone else wants to come in late. To me, whether
someone comes in at 6:00AM or 10:00AM has nothing to do with the work to be
done. In our environment, it would be needlessly rigid to dictate that
everyone work 9 to 5, and bureaucratic to think that someone who works 7 to 3
somehow isn't working as long or as well.
On the other hand, let's say that after much research we arrive at an optimum
way to make PDF files (I wish!), and we document the process. If one writer
were to ignore the process and make PDF files his own way--with inferior
results--I would insist on conformance. On the other hand, if he comes up
with objectively better results, then I will want everyone to adopt it.
To me, restricting working hours without reason is bureaucracy, while
insisting that everyone follow the best known production method is process.
Andrew Plato used an example that makes the distinction well. If your group
has a policy that a writer should speak to the SME at the beginning of a
project, I would say that's good practice, and I would question a writer who
consistently failed to do so. On the other hand, if the policy dictates that
the meeting must be one hour, I'm sure you'd agree that it has degenerated
into bureaucracy--what others can do in one hour, I might be able to do in
twenty minutes. Or maybe I need two hours.
There is a danger that one man's process is another man's bureaucracy. We
instituted an industry-standard policy that all documents must be signed off
by key reviewers before going into production. One of our writers ignored the
new policy: he sent his stuff to review and then straight to print. He
finished his work faster with less effort and no paperwork; I suspect he
thought himself efficient and clever. I didn't notice for a while that I was
seeing review drafts but not signoff drafts; later he claimed there wasn't
time for signoff. But I did notice that I kept making the same editorial
comments in his documents, revision after revision; and later I learned that
Engineering disliked working with him, because he ignored their comments,
too--technical comments. And there was no mechanism to see what he'd done
before the books were in print. Eventually, he left the group, then left the
The writer who didn't send his work to signoff may have thought the policy
bureaucratic, but there were negative consequences for ignoring it, and he
simply wasn't getting the work done. As a result of this episode, I began
tracking when documents go to signoff; I can tell you what percentage of
documents now go through the process (and implicitly what each writer's level
of conformance is). I claim tracking this metric helps ensure best practice
and thus improves work quality, although one could argue I'm a bureaucrat for
tracking signoffs instead of sending out books of my own 8^)
Steven Jong, Documentation Team Manager ("Typo? What tpyo?")
Lightbridge, Inc., 67 South Bedford St., Burlington, MA 01803 USA mailto:jong -at- lightbridge -dot- com -dot- nospam 781.359.4902 [voice]
Home Sweet Homepage: http://members.aol.com/SteveFJong