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.
> >But can process
> >help? I think so, if the whole organization buys in to them.
> =====================================================
> Your statement reminded me of something I already knew, but failed to
> dredge up as the ultimate response to those like Plato who think
> structure, process, and standards are often counterproductive.
Standards are often counterproductive because they are not used as a tool, but
as an excuse. Also, most people don't buy into them - because they are lorded
over by one or a few and cannot accommodate the realities of daily work.
I don't think structure or process is evil - just constraining. That can be a
good thing (efficiency) or a bad thing (stifling creativity). And there are
times when structures need to be torn down and replaced.
> I doubt if any of those anti-process folks would grant that same freedom from
> restrictive processes to other departments of the company in which they work,
> particularly the engineering groups upon which they rely for the information
> they require. So, as I suggested in the post which started this thread,
> anti-process folks want to be able to blow smoke up their own ass (as well
> as everyone else's) without a reciprocal smoke-blowing entitlement granted
> to the other departments. They think they're entitled to some kind of plenary
> indulgence that liberates them from the restrictive processes imposed on
> others,
Are you kidding? Most departments already are totally devoid of process, even
the ones that think they have it. I have yet to see a programming team that
follows their own specifications.
Many departments are forced to deal with whims. Be that the whims of some
manager, the whims of fate, or the whims of users. Whatever the case rigid,
unflappable processes are not well suited to whims. Unfortunately (or
fortunately) today's economy is all about whims. The hot, wild crazy thing of
today is the forgotten nothing of tomorrow.
Process and structure must develop naturally from the individuals who work each
day with their respective "content". Programmers must develop processes, but
do so in a way that respond to the volatile and changing nature of business.
Dan, this isn't a "we're out to get you" kind of thing. People like me just
aren't willing to accept a stupid process just because it is trademarked or
because somebody says "that's the way we always do things." If a process isn't
producing results - quality, accurate, profitable results - it must be scrapped
or changed. Typically scrapping a process means some interim chaos while you
find a new process. Those chaos periods are good, because chaos is where
ingenuity and creativity originate.
Lastly, I am not "anti-structure"
I am anti-bullshit, anti-excuses, anti-lazy, and anti-obsession. I build
development teams where people, accuracy, and content is paramount. Apparently,
you and Tim (and others) prefer teams where process, hierarchy and structure
are paramount. That's cool. I just don't think that is the best way to do it.
