Re: multiple TWs for a project

[CBamber -at- castek -dot- com]

Subject: multiple TWs for a project
From: gyaker -at- csc -dot- com
Date: Wed, 9 Feb 2000 12:27:57 -0500
X-Message-Number: 25


Gil Yaker asks:
>What's it like working on a team of tech writers? Lets say 1, A small team
of
>3-5 and 2, a larger  team like the type that would work on a highly
formalized
>project.

Me:
Way more fun than working alone, if you're inclined to enjoy working with
other human beings. Challenging. Not necessarily "highly formalized". I
believe in
strong process, but only to the point where it helps people and creates
better
outcomes - and processes and how we think about them have to be flexible
to accommodate a variety of situations.

Gil:
>It's hard for me to see that teams can create
>documentation with any real consistency. I did work on a 3 month project
with
>another TW and found myself butting heads with her on a few occasions. And
>regardless of who was right, it seemed nearly impossible to keep all of
our work
>perfectly consistent given such a short time frame.

Me:
Having done it, I can say that it doesn't present a particular challenge. A
recent
short project (4.5 months, 14 people, over 6000 pages of documentation) is
very consistent.
You ensure consistency by using templates, a style guide, strong editorial
process and
getting everybody on the team to buy in to the fact they are working on a
team with a
"team voice" that they are responsible for learning and using.

Gil:
>In the same spirit, I'm kind of hard-headed in so much as sentence A can
clearly be
>better than sentence B, and to this I would fight to the end.  Are people
like
>this a detriment to a team of tech writers, especially if they are not in
the
>Sr. position?

Me:
People like this are exactly the kind of people I like to hire - but
they're also a lot of
work :^). (Really good people who are also passionate are often a challenge
to manage, but that's another thread)
Passion is good. But it needs to be directed to the right things - to
things that count in your project and in your circumstances. If it isn't
focussed constructively, then it is a problem. No-one on my teams ever
*fights to the end* about sentences. There are a number of reasons why not:

* Editorial ground rules that everyone agrees to follow: these include
principles like "if the peer editor
or tech reviewer thinks the sentence doesn't work, then it probably doesn't
- although it
may need a different change than the one specified", "adherence to team
voice wins as long as it isn't stupid",
"consistency wins as long as it isn't stupid",  etc.

* Personal ground rules that everyone understands and agrees to follow:
"Everyone on this team
has lots to learn", "Behaviour that demonstrates mutual respect is required
at all times", "everyone
on this team brings specific strengths that can be capitalized on", "spare
us your ego",
"check your attitude at the door," etc

* Business ground rules that everyone understands and agrees to follow:
"This is a job, not my life or personal identity", "Cost matters", "We have
limited time and resources - we must produce the best thing possible
in the time we have for the budget we have"

* Judgement ground rules: "use the good sense you were born with", "Save
your battles for
things that are truly important"


Gil:
>I am worried that if I work on a team of writers,
>especially under a senior who I don't 100% feel employs the best tech
writing
>practices, I would be quite unhappy. This also applies for working
alongside
>incompetent TWs.

Me:
I had an experience some years ago where a person I was working with
deplored
the competence and behaviour of a certain manager, and then was promoted
and had to do
that job himself. He immediately started doing the same things the previous
manager
did. It was an important lesson.

The point is that there are more factors at work here than simple producing
ideal documentation using ideal processes and ideal resources, and the
person responsible for
deciding what work gets done and how, has to take all those factors into
account. Many senior writers/managers buffer their teams from those
considerations.
I don't, personally, because I believe that a team that understands
everything that goes on,
and participates in the decisions will buy into those decisions and take
personal responsibility for implementing them.

For example, for a project, we might have $500,000, 4 months until the
documentation
is needed, 4 intermediate writers currently on staff, a huge new product
with not bad
specs (50% are reasonably up to date),a preliminary estimate that the
project will
require in the ball park of 6500 hours to complete,
the VP of marketing thinks techwriters are the biggest waste of time and
money in the universe
and thinks that the project should be done by developers and Business
Analysts, all the
business analysts but one are on a new offsite project and not availabe to
answer
questions. The developers are great and one of them would like to work on
the documentation
project and another could be pursuaded to. The BA and developers have no
techwriting experience.

As a manager, I now have to make trade-offs. I need to add 8-9 people to my
team. If I include
the BA and 2 developers I get the advantage of their advanced knowledge of
the new system, and
the VP will be molified, but someone will have to mentor their writing,
train them as we go along
and they will require way more editorial than my current team.  If I have
to hire off the street,
do I hire the best TW's I can find, or the people who will fit into the
team and work well together?
Which brings more advantage - a junior with a great attitude or a senior
with a chip on her shoulder?
do I want all career TWs or will we move some of these people into
different roles after the project
is over?

What process do I use? What can we eliminate from the process to meet the
time deadline?
There is no money to pay overtime - what infrastructure can we put in place
(or reuse) to maximize
reuse and minimize rework so that people can go home at night? Will the
advantage be
offset by having to learn a new tool? Do we use an assembly line
model (fast, but not very satisfying for individuals) or give each person
their own
piece to take from analysis through writing through print (much more
satisfying, and a better
learning/developmental experience for each team member, but slow). How
mature is the
team - how much stress can I realistic expect them to tolerate?

How do we control consistency among writers? is consistency more important
than the best
possible sentence in each case? If we use minimum standardization, writing
will take less
time, editorial more time. Is our team made up of stronger editors than
writers? Will more
standardization help less experienced writers?

How much content is enough? If we can't get "enough" content in given the
other
constraints, which content gives users the most bang for the buck?

These kinds of decisions rarely lead to 100% Ideal Techwriting Practices -
but if
they are well considered, they allow a team to get the best possible thing
out in
the circumstances where they find themselves.

I put all the factors on the table when we start a project and let
everybody have their
say. Once we've agreed on what we are doing, the arguments are over.


Gil:
> But I don't think that the majority of TWs out there have the amount of
>experience and insight as many of you.

Me:
I've worked on some horrible teams - and some great ones. All you can do is
open your mind and learn what works
from working on great teams, and learn what doesn't from working on crappy
teams and apply what you've learned
when it's your turn to be in charge.

When you aren't in charge - part of the TW job is "working well with
others" (recall the team player thread). To me, that means
making the best of whatever circumstances you find yourself in, learning as
much as you can, contributing whatever you have,
being respectful of everybody else and always being part of the solution
rather than the problem.

Anyway, back to it.

Candace
____________________________________
Candace Bamber
mailto:cbamber -at- castek -dot- com

Castek
Putting the Future Together