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.
> I'm truly astounded by some of the replies on the "Drafts" thread. What
> amazes me is the acquiescence shown by some people (not everyone) to the
> idea that one must please the boss at all costs.
He/She who signs the checks makes the rules. Been that way since just about the
time apes grew thumbs.
> A manager must demonstrate some minimum level of respect
> for his people, as well as some minimal level of intelligence. A working
> partnership is a 50/50 proposition, and if managers don't demonstrate these
> qualities, then, even in hard economic times, one quits and moves on.
Yeah, you're looking for la la land, that's two lights down past world peace and
Linux users who like Windows.
> As for the draft issue itself -- look, this is not brain surgery Projects
> in development are not complete, and different aspects of a project in
> development are in different stages of readiness. An intelligent reviewer
> is obligated to read and review in a discriminating fasion.
That sounds great on paper. But it just doesn't hold up in reality. Not everybody
cares about the state of your project. Basically, you have to roll with it and
accept the good help with the bad help.
You are asking them to review your documents on your terms. While you're at it,
why don't you demand that they pay you based on your terms...get serious, Steve.
People are not going to just adopt your reviewing terms just because you think
they're the correct ones.
> Let's use an analogy with software. Say it's software that supposed to be
> doing some fancy calculations; the programmers may have the user interface
> ready, but the calculation engine may not be complete -- or, vice verse,
> the calculation engine may be in pretty good shape, but the user interface
> is still in rough form. Either way, it's perfectly appropriate, in an
> intermediate stage, that the software engineers should to management (or to
> QA testers, or whomever) and say, "This is partly done -- we need you to
> review the part that's finished (or semi-finished), and ignore the part
> which we are *telling you in plain English is not yet finished*." Check
> the user interface, or check the calculations -- whichever part we think we
> have working -- make sure we are on the right track here, before we dig in
> any deeper -- while we keep working on the rest.
Been there. And usually QA does log the bad UI as a bug. Its just the way it
Real simple Steve: if you don't want your interim work judged, keep it all to
yourself until its all ready for its grand entrance.
> It's no different with a document. Different aspects of a document can be
> in different states of readiness, and its often appropriate to review a
> document -- reading for some things, and ignoring other aspects -- as a
> document is in progress. And the gripe here is with some managers -- not
> all, but some -- who are frankly either too dumb or too anal to read
> selectively. I don't care if it's a character flaw or a lack of
> intelligence, these people have no business supervising the work of those
> who are actually being productive.
They have all the right in the world to analyze those portions. Just as you have
the right to nod your head and smile and chill out over their criticisms.
There are just as many dumb managers as there are dumb technical writers.
> Mr. Plato and I have already exchanged a few e-mails privately on this
> issue, and we just have a very different view of life. I don't want to put
> words into Mr. Plato's mouth, but he seems to feel that the goal of the
> worker bee is to keep the boss happy under pretty much *any*
He who signs the checks...oh, I said that already.
This is pretty simple: either you put up with your boss or you leave.
If you are not willing to work with your boss under his/her terms, then you need
to leave. If you are not willing to leave, then you need to find a way to work
with your boss under his/her terms. You can try talking to him and EDUCATING him
on your needs. But you cannot expect your boss to suddenly reverse his/her
management style just because you are unhappy. If you are unhappy, leave. Go find
a job that more appropriately matches your needs. Otherwise, STFU and get your
The boss is the boss. And you either work with him/her and negotiate a space or
you take off. Raging against the machine will probably just backfire and get you
fired or at least "put in a box".
>Believe me, I care about my work, and I have integrity. I
> want to do a good job.
Everybody says that. Its like "I'm a fast learner."
You can have integrity about your job and still make your boss happy. Even if
your boss is a butthead.
Moreover, your boss just might be...correct. And if you listened to him/her, you
might learn something.
> But I can only do that if the employer provides a
> context which makes that possible. I have certain expectations for my
> leaders or managers. The fact is -- and this too is not brain surgery, we
> all know this -- some people get into management or other leadership roles
> who just have no business being there. My clients are fortunate to have me
> work for them, because I do quality work.
Somebody call John D. and Catherine T. MacArthur.
> If the client, or their specific
> representatives -- the managers -- can't do their 50% of the job to make
> the relationship work, then it's the company's loss when I go elsewhere.
Did you ever think they might be happy to be rid of you?
> Some people in the thread have said that, as technical writers, we need to
> educate our bosses. I don't accept that assertion either. I'm a writer,
> not a business school professor. The managers are already supposed to know
> how to do their jobs, part of which entails both being flexible, and giving
> their subordinates breathing room in which to work.
The fact is, you need to be educating EVERYBODY in your company about who you
are, how you work, and what you expect. If you show up and on day one start
demanding people respect you, I can GUARANTEE you that you will not succeed. You
have to EARN respect. And therefore you have to educate everybody on how you work
and fit into the larger scheme of your company. That means asking questions,
finding out what is expected of you, and then explaining to people what you need
and what you see your responsibilities as.
And just because you think your responsibilities are X Y and Z, doesn't mean your
boss has to or will agree with you.
> Good leaders understand context, and most importantly, good leaders
Good leaders - lead. And leadership is more than prioritizing. Its a combination
of many factors: motivation, vision, maturity, experience, organization,
education, etc. And sometimes good leaders have very exacting standards. And if
you want to work well with them, you need to meet their expectations. Honestly,
the best leader demands a lot from his/her team and religiously holds people
accountable. A good leader also refuses to allow people to get mired in petty
little wars or blame games. A good leader is also proactive and cuts off problems
before they grow into larger issues. And sometimes that means looking at work in
progress and making sure that the people repair what is still deficient.
People who are anal about how their work is judged, usually have something to
hide. This is true of managers, programmers, CEOs, and yes, technical writers.
What is the first thing convicted criminals say "that was and unfair trail." Of
course it was unfair to them - they lost.
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo! http://sbc.yahoo.com
Experience RoboHelp X3! This new RoboHelp release combines single sourcing,
print-quality documentation, conditional text and much more, into the most
monumental release of RoboHelp ever! http://www.ehelp.com/techwr-l
FrameMaker-to-PDF TimeSavers Assistants let you enhance & automate navigation
in PDF doc sets (chapter tabs, next/prev chapter/pg, bookmarks, popup menus);
create interactive PDF forms, rollover popups; presentations: http://www.microtype.com
You are currently subscribed to techwr-l as:
archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit http://www.raycomm.com/techwhirl/ for more resources and info.