Tarage wrote: : Implementing change : in a small company requires an abundance of social skills, : which it sounds like you've already discovered. :)
Yes - that's one of the reasons I make a point of "lunching with the boys" and sticking around for drinks and so forth :) I draw the line at joining the cycling team, though! : Getting people to agree on a standard is the hardest thing, I think. : That lays the axe at their tree of independence and tends to : elicit howls of "But this is how we've *always* done this" : and "I've worked here for 20 years, and..." and "That's now : how company XYZ does it!" It's somewhat easier when they recognise that it's time for a change, but there are always a few things that they won't let go for some inexplicable reason. My pet peeve is made-up words to describe a process that can be adequately described using plain English. : Nevertheless, if you want to convince them that technical : writing is best left to the experts (and it isn't just : something that they can do in their spare moments), getting a : style guide approved is the first thing to do. I suspected as much, and I think after our efforts in devising a common terminology guide, they also now realise that some of the things I included are better addressed in a separate style guide (oh, now why did I put that in there? Perhaps it should go in another document? *innocent stare*). It got them thinking, that's for sure (hopefully not too much, though!). : The step : after that is to get a review by technical writers before the : words reach the customer. A few pages of dripping red and : they'll find it even less fun. :) Having management support : on this is critical. If those folks waver, the process unravels. I'm about to submit my first review, and pages dripping with red is right on the mark. Luckily, my first mark is a developer who was quite open about not knowing the first thing about writing - but I realise it's still a hard blow to deliver. The developers are easy, they're usually quite frank about their lack of writing skills. The PMs or aspiring PMs, not so much. This bit is hard, actually. My PM mentioned to me today that it was suggested to him that I completely take over writing all of the manuals, which was encouraging. Unfortunately, I have a deadline in a month and I don't have time to do it all, at least not until after Christmas. But getting the PMs to submit to a review? I don't know, will have to feel that out, I guess. Handing off a job is one thing, putting oneself up for potential humiliation is another (not that I see it that way, but being on the receiving end of "pages dripping with red" is never pleasant). But at least it sounds like they're not feeling threatened by my job. : the brick wall was management. They viewed : such ground-up developments as a threat to their power, and : thought it made them look less-than competent. In my last company, this was definitely the case. An unfortunate side-effect of extremely intelligent people with egos to match ;) : A second wall : were the information hoarders -- people who would under no : circumstances let go of a part of the process; they had : worked there for years and were scared to death that they : could work nowhere else. This is a shame, especially when combined with the above. I haven't come across any yet, but will definitely be on the lookout. Thanks for your insights! Trish :) _______________________________________________ Interested in Interactive 3D Documentation? Get the scoop at http://www.doc-u-motion.com Your 3D Documentation Community. _______________________________________________ Technical Communication Professionals To post a message to the list, send an email to [email protected] To find out more about the list, including archives and your account options, visit http://techcommpros.com/mailman/listinfo/tcp_techcommpros.com If you need assistance with the list, write to [EMAIL PROTECTED]
