Re: In the Trenches, A Bit of Venting

["Gary S. Callison" <huey -at- interaccess -dot- com>]

Andrew: 

1) I don't need you to CC me on list messages. One copy is enough, thanks.

2) 
On Sat, 16 Nov 2002, Andrew Plato wrote:
> "Gary S. Callison" <> wrote ...
> >   ...it's not deadline day you spring this on your boss- because at
> > that point, the project is on the line. No, the instant I realize
> > that my working relationship with this person is going to impact the
> > quality of my work, I go to the boss and play the whole hand face up. 
> ...and the boss says "figure out you two, the docs are due in 2 weeks."
> And you're right back at ground zero. 

This situation has never happened to me, in twenty years of gainful
employment. I _have_ had my share of impossible deadlines- and I have hit
most of them. At one point, I had to recruit most of the sales staff and
my boss, and all of us worked until after 1AM to make an impossible
deadline, but it turns out that t'warent impossible after all.

> Moreover, is it your job to see that everybody meets their deadlines?
> Are you the boss? 

It's my job to hit my deadlines, and inform my boss when I have inadequate
resources to do that. What they choose to do with that information is out
of my control- but the overwhelming majority of the bosses I've had
appreciate candor and give help when you ask for it. 

I'm abundantly aware that not all bosses are like this; my advice is to
choose your employer with more care next time if this happens to you.

> > And most of the time that I've gone
> > to management with "I am having real problems dealing with X on this
> > project", the answer is something like "You didn't hear this from me, but
> > you don't know the half of it. X is driving EVERYBODY NUTS. Is there
> > something I can help you with instead?" The boss appreciates my candor,
> > and helps me find other ways to get the product out the door on time.
> Sure, if you work in a "lets play the blame game" kind of company, then
> this might work.

It also works in organizations back here in the real world, where the
goal is to produce what the client wants. My first reaction to reading the
rest of your post was "Now that's a curious, ill-informed, and inaccurate
characterization, bordering on an insult, of damn near every organization
I've ever worked in", but then I saw, in the thread "Re: Proof that
content is more important than style:
henning -at- r-l -dot- de (Jan Henning) wrote:
> Andrew Plato wrote:
> | Now, some people are just simply obsessed to madness that content and
> | style be given equal weight.
> Andrew, I'd appreciate if you'd stick to the arguments and leave out
> speculations about the state of mind of their proponents or distortions
> of the manner in which the arguments are presented ("scream, holler,
> throw a 1000 simultaneous fits") that amount to nothing more than
> thinly vieled insults. Thank you.

That's far more polite than I could put it, but what Jan Henning has said
goes double for me.

>  Blame-based organizations predicate every job with
> rationalizations and blame, such as: 

Blame-based organizations? What sort of product do they produce? Is there
good money in that? All the places I've ever worked have chiefly concerned
themselves with getting the product out the door on time and under budget.

> 1. We can't meet the deadline because SME 1 and SME 2 won't get back to
> us with the information.

Get it somewhere else. Information rarely exists in a vacuum.

> 2. I can't do all this work by myself because Mr. MFA won't help.

If you're stuck, ask for help, or suck it up and work long hours until
you're caught up. 

> 3. We need more resources so I can fritter away 9000 hours fondling
> fonts to ensure perfect template unity. 

Anyone who does this deserves to lose anyways. An 80% solution on-time
always beats the perfect answer two months late.

> 4. We all hate Mr Z and he is the root cause of all the problems here. 

If Mr Z can't be a team player, he'll find himself out of the loop and
irrelevant in due time. If I need something from him right now, and I'm
stuck until I get it, can get it nowhere else, and management is
unsympathetic? Make sure everything else on that project is as done as I
can get it, make sure my communication problems have been addressed with
management and documented, and move on to the next project. Deadline hits,
project ships, and I get asked "How come this is..?" the answer is "You
remember that meeting we had, I followed up with an email on July 11th..."
and my ass is covered.

> Rationalizations are the realm of people who essentially don't want to
> do their job. Or more specifically, they like one part of their job
> (usually the fun stuff like fiddling with fonts and processes) and
> therefore will make up an endless series of excuses why they need to do
> that - and not do something else - like write the damn docs. 

Sometimes, the process _is_ the problem.

Picture this: Long-faced developer in the elevator, 
  "I just got chewed out by the client, for delivering something that's
   'not what we asked for'."
Well, did you hit them over the head with the requirements document? 
   "Uh, what requirements document?" 
Wow, Ace, looks like you shot your own foot there! Wrote some software
without a plain-english description of what it was supposed to do in the
first place, it's no wonder they don't like it. I don't need a
'rationalization' to tell me that the process that culminated in that
meeting is broken, and I don't need management to tell me to stop writing
on project X to figure out how to fix it and start doing so. Our job
isn't blame, it's to deliver the clients what they want. In order to do
that, we have to have an agreement between us and them that says what
that is. Project X will get done on time instead of three weeks early as
a result, and I'll also have a requirements document for Ace's new
software package.

> Blame-based organizations are weak and ineffective. They produce
> sub-standard material because everything is done in a clumsy and
> unfocused manner even when internationally STC-approved documentation
> methodologies are used. Blame-based organizations rarely have the drive
> and ambition to creatively solve problems. The people in these groups
> get stuck in a rut of "that's the way we do things around here." Never
> mind that the way things are done is astronomically stupid. 

This is a lengthy diatribe at a hypothetical organization that I can only
assume you believe to include myself. It doesn't, but since I have no
experience working for an organization that exists primarially to assign
blame, I cannot refute any of your points. 

> A solutions-based environment refuses to allow blame to be assigned.

Failures happen. Those failures are the responsibility of one or more
people- the guy who signed the contract, the project manager, the team
lead, the person actually doing the work. After those failures happen, and
those people are identified, the grownups among us will say "Yeah, I
screwed up there. I didn't give myself enough time to do X" or "I didn't
spend enough time bugging the SMEs" or "I didn't plan this as well as I
could have", or what-have-you. 

>  Rather, failure is just a reality and dealt with as a problem to be
> solved. Sometimes that solution is to remove people who consistently
> fail or demand to ?re-engineer? their job so they don?t have to do
> ?hard work.? 

When you find one of those jobs that doesn't involve any hard work, please
let me know.

> I realize many organizations are obsessed with blame. That is usually
> due to a crappy corporate culture. But you are not doing them any
> favors by going along with that work ethic. You're just following the
> lemmings over the cliff.

I've been called a lot of things, but never a lemming. Please spare me
your ad-hominem and stick to the subject.

-- 
Huey



^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Order RoboHelp X3 in November and receive $100 mail in rebate, FREE WebHelp
Merge Module and the new RoboPDF - add powerful PDF output functionality
to RoboHelp X3. Order online today at http://www.ehelp.com/techwr-l

Check out SnagIt - The Screen Capture Standard!
Download a free 30-day trial from http://www.techsmith.com/rdr/txt/twr
Find out what all the other tech writers, including Dan, already know!

---
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.