Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site decwrl.UUCP
Path: utzoo!watmath!clyde!bonnie!akgua!whuxlm!harpo!decvax!decwrl!dec-rhea!dec-lymph!arndt
From: arndt@lymph.DEC
Newsgroups: net.flame
Subject: Re. Ken Arndt Ozone Bluze
Message-ID: <2564@decwrl.UUCP>
Date: Sat, 8-Jun-85 02:53:57 EDT
Article-I.D.: decwrl.2564
Posted: Sat Jun  8 02:53:57 1985
Date-Received: Mon, 10-Jun-85 20:47:33 EDT
Sender: daemon@decwrl.UUCP
Organization: DEC Engineering Network
Lines: 150

Hutch replies to my puff of DEC with a whine about Tekbondage Co.

He says:
Ummm, If you look at the header (that stuff that includes the name, address,
keyword limes, etc.  you'll see a line that says 
	Organization: Tektronix, Wilsonville OR

                  *** Sorry, thought 'tekronix' (as my machine reads it)
was a cute name for a node.  Wilsonville, eh?  "Say no more, say no more,
wink, wink, nod, nod."

Hutch labors on:
We're not a "rabbit company" at all.  We've been around longer than you
Dec'kies and came within 50Kbucks of owning half of this upstart company
called "Digital Equipment Corporation" back in the late '60s or early '70s
when y'all had over-extended your cash and wanted to pay in stock for some
scopes and test equipment.  Unfortunatly Tek management was sometimes a
tad short-sighted...

                  *** A great story!  Reminds me of my Uncle Parsimony,
on my mother's side, telling about how he could have cornered all the
McDonald's stock and turned it down.  He has a 'Mac Attack' every couple
of miles down the road.  But glad to hear that you're not a 'rabbit' co,
even if, as you say, they're 'short sighted'.

[I, ahem, mention my exhalted title - Hutch replies with:]
Hmm... Management you say.  So that's how you can afford to waste all this
net bandwidth!
                  *** One man's waste is another man's treasure!  Personally,
I treasure the sound of my voice.  Besides, hanging out here on the net comes
under OJT for me.  Look at all I have learned about computers!  They DON'T
need to be shut down to cool off and check the battery oil.  And if you can
read a time stamp on this message - where would that be? - you'll see that it
is after midnight or so, so I'm on my own time even if I am still here at
work (wink, wink, nod, nod).  Opps!  I just fell off my chair!  See, I'm
getting more technical all the time.

[Hutch drags on:]
As for slippery schedules, I don't know anything about your group, but I do
know that Dec has its share of slips, and judging from other replies from
inside Dec, Evaluation gets the short end there just like everywhere else!
And as far as "valid reasons" goes, "valid reasons" are whatever the upper
management, who follow the bottom line of sales, says they are, and it takes
a lot of expertise and a real good justification to say no to them.

                      ***  I have also worked for Honeywell and for 
Data General.  I know what you mean about the ubiquity of 'slippery schedules'.
But it has been my experience that most, if not all - since time should be
built in for technical slips and large ones largely avoided by proper design
and specification -, slips are 'people' or 'process' caused.  And those can
be 'worked' by a, ahem, good Product/Project Manager.  There are various cute,
in color graphics yet - always wows 'em in staff -, project management tools
to help deal with 'people' and 'process' schedule slippers.  For example, and
one I love, when someone - always a Marketing type who understands nothing of
what it takes to actually PRODUCE a product (hardware or software - I've been
involved in making both) comes running in with this great idea for added
functionality that he came back with from some convention in the islands,
"The Market DEMANDS this!", ( I've got to get to Marketing - three piece suits,
expense accounts, trips, yuppie women) why just say sweetly, ok, let's see what
the computer (get it?) says it will do to delievery time and/or how much more
resources (money/people) you can help us come up with.  Ahhhhh, gee.  That's
too bad.  Well, let me put it down for the next go round of marketing 
requirements.

          'Process' slips usually turn out to be either 'people' problems
at bottem, and as Al Capone said, "You get a lot farther with a kind word and
a gun, than with a kind word alone.", or a matter of 'working the system' to
advantage to keep things moving.  Shorten time lines by 'parallel processing',
sort of.  And the use of arcane project management techniques ("I'll tell your
boss!", "Want an Official Project Coffee Cup?") and management jujutsu.

Let me regale you with a war story from Ken's story bag.  Once
I had to give a presentation on my product - not at DEC - to 'walnut row' and
I and my manager arrived at the proper time all dressed up (matching socks) 
with overheads, telescoping pointer and happy face smile seasoned with a
worldly professional concern pasted on my face.  Now what motivates Olympus
gang?  Right!  "On time and within budget!"  They don't want this morning's
count of how many engineers are in their chairs and how many fell off and are
on the floor.  They want to see their that their decisions are being carried
out by intelligent people and if they made a mistake and you really can't get
five pounds in a two pound bag, they want to KNOW about it before you run out
of bags and what YOU propose to DO about it!  They want to make a pile, not
get them.  I always (it was whispered to me at a Project Management Assoc.
dinner) at that level of reporting show trouble by listing concerns and risks.
Concerns are being addressed and risks no one is looking at.  And only a ninny
lists risks.  Or has them on his project for long.  Anyway, at the sum up one
must ask for questions.  From the back of the room comes this voice asking me,
"What about the problem with the 'shotkey' devices?  I don't see it listed 
there as a risk to your project."  My manager is giving me a stage whisper,
"What's he talking about?  Did you know about this?"  I didn't know what a
'shotkey' device WAS much less what was wrong with them.  So what to do?
Remember, there are VP's in the room who may know my name if this gets out
of hand.  Should I turn to my manager, haul him to his feet by his shirt front
and say, "I think I'll let you answer this one Bill.", or should I lie my face
off and hope no one starts a chant, "HE'S LYING, HE'S LYING", or say "Duh, I
don't know", or assume a fetal position for three years?  Right gang!  I lied
my face off, sort of, keeping in mind my definition of 'risk'.  I said, "The
reason I haven't listed it as a risk is because the issue is being worked."
(pause) "Are there any more questions?"  (pause) "Thank you."  Well, as soon
as I got out of there I shot like a rocket to find out what the heck this guy
WAS talking about.  Came to find out there was a problem but those devices
were not used in my project and the guy was blowing smoke.  You have to take
risks and push back.  The project process and the people involved change with
every project it seems so that by the time you realy know your way around it
doesn't matter any more - the project launched or sank.  So use jujitsu!
Not many engineers, being plodding mechanical/mathmatical process directed
types, are good at Product Management.  Sometimes it takes a Nurf ball like
me.
  
          As for your attempt at humor - I hope you were smiling when you said
it - with your reference to Evaluation getting short shift at DEC, well let me
say that 'Field Testing' in the customer's cash flow will not lead to a success
story like DEC's!

[Hutch continues on about managers not controlling slips:]
You betcha people get away with that.  Even at Dec, although there they seem
to call it "the next revision" and have a slightly more formal method for
inflicting it on customers, called "software support" ... not to slander
software support, most of my friends at Dec are doing that sort of thing.

                 *** Don't worry about slandering software suport.  Everyone
does.  Some of my best friends are in SWS, but I wouldn't want my sister . . .
Product revision is a valid method of product CONTROL.  Remember, the idea
is to get to market with what you have NOW.  The target is always moving.
There are penalities, market and personal, for 'getting away with it'.
So in the long run you don't really.  DEC is known for its high quality
of support and service.  

[Then Hutch turns cranky:]
Of course, I could discuss things like the various changes which are made
to Dec software without the formality of changing specifications, or the
difficulty of doing original, cutting-edge stuff which hasn't really been
done before, on a very large scale, with lots of very bright and very
egotistical people, and still doing everything exactly right without the
need to change anything.  Now, even though this is net.flame, I will be
nice and avoid suggesting that you don't have this problem :-).

                  ***  Ahhh.  Go ahead.  Don't be nice.  I agree that engineers
sometimes hate to document what they are doing.  It's not as much fun as 
actually doing it and the next project/problem is awaiting.  


                  Well, It's been fun Hutch.

Go ahead and pay cash if you like. I prefer to use other people's money
to finance my style of life.

Regards,

Ken Arndt