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: Radical management From:Gwen Thomas <thomasgp -at- CBS -dot- FISERV -dot- COM> Date:Thu, 11 Mar 1999 13:37:10 -0500
Sometimes we manage existing processes used to produce existing products.
But... sometimes we're called upon to architect new products or processes. Seems to me these two sets of duties can sometimes require vastly differerent approaches.
If it's a tried-and-true process, I would hope for (or hope to be) a manager such as Geoff Hart and Mark Baker and Jim Aikens described. With such an open and flexible approach, a team shouldn't "crumble" even if strict standards for templates, styles, etc. are enforced.
If the group is developing a new knowledge product, however, my feeling is that, ultimately, there MUST be only one chief architect. I would hope that architect would be getting input from all available sources and would make the design process a truly collaborative process. However, at a certain point, someone has to be in charge. (You wouldn't want to work in a building where the carpenters decided to use balsa wood instead of steel, or where the electrician decided to skip fuse boxes. And our embedded help team would never have been able to reconcile RTF codes with application codes if everyone just took a shot at it. We had to develop a systematic, scientific-method approach and follow it. )
So here's a question to you all:
For yourself, or for your team, how do you handle switching hats between manager and architect? How do you encourage your team to switch between appropriate work modes? How do you approach work style choices vs. those that have a serious impact on productivity? How do you gain the benefits of fluidity while maintaining the benefits of standardization? For those of you who don't think of yourself as scriveners or scribes or artisans, what mental models do you employ when designing work flow within a large enterprise?
BTW - this list has suddenly become fascinating. I've used my entire lunch hour reading the digest and can't wait till tomorrow for another one. I'm going to have to switch to individual emails and just take my lunch a few minutes at a time over the day...
