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:Arlen P Walker <Arlen -dot- P -dot- Walker -at- jci -dot- com> To:techwr-l -at- lists -dot- raycomm -dot- com Date:Tue, 07 Sep 1999 12:49 -0500
Andrew, with an eye for hyperbole I sometimes envy, seems to have placed a
fingernail on the artery of this.
There are a lot of myths about process and efficiency, not the least of which
is that chaos and bureaucracy are opposite ends of the process spectrum. This
is a fine example of something that "everybody knows," but that still isn't
The confusion is understandable, but I think we can get past this by defining
the term a little more openly. Bureaucracy is the worship of process over
product. The process doesn't have to be efficient; it doesn't even have to be
orderly. It just has to be The Main Thing.
The trap to be avoided is:
P1) Bureaucracies can't get anything done.
P2) Bureaucracies use a process to achieve this.
Therefore all processes prevent things from getting done.
Another myth: process are Good. Processes can help or they can hinder; for
instance, the process of hitting a key on the keyboard is quite well-defined,
yet it doesn't get in the way of creativity and excellence, because we don't
focus on the process, we focus on the product, the letters and words on the
screen. But it's the fact that it's so well-defined that allows us to take our
focus off the actual pressing of the keys and put it where it belongs. Try
randomizing the keys and see what happens to typing.
OTOH, an overuse of boilerplate text and obfuscate (or even omit entirely)
necissary information. But the use of this is also a process, and a
well-defined one at that. Good. Bad.
Another myth: processes make things faster and more efficient. A bad process
can slow you down just as easily as no process at all. I have sign in my office
(yes I have lots of signage for my walls, replacing them periodically)
"Standards and procedures are all right in their place, but they should never
get in the way of getting the work done." That, to me, is the main criteria
between a good process and a bad one. Good ones promote production, bad ones
Another myth: processes are rigid. Every good process has a built-in feedback
loop to adjust it. If it doesn't it's not a good process. Period. The feedback
loop has to have an anchor in reality, that is to say, related to the actual
product. That's the only workable measure of whether the process is working,
after all: the quality of the output.
And that's what it's all about. It's about helping the majority of workers in
the middle of the bell curve (oh, I know, there's no one on this list in the
middle of the curve, and every manager out there only hires above-average
people) to do their best work without imposing a burden on the gifted few (who
will quite probably perform superbly even using the process). You check your
feedback loop (um, your process *does* have a feedback loop, doesn't it?) and
tune it as you go.
Oh, and while I'm exploding myths, here's one for Tim: Apple and Gateway's
units shipped per month are far from the 6:1 ratio he's positing. They're
within 70K units of each other: Gateway at around 1 million for Q3 99 and Apple
at just over 900K for the same period.
Chief Managing Director In Charge, Department of Redundancy Department
Arlen -dot- P -dot- Walker -at- JCI -dot- Com
In God we trust; all others must provide data.
Opinions expressed are mine and mine alone.
If JCI had an opinion on this, they'd hire someone else to deliver it.