An EMail Flame War

at Macro Laboratories

L. Perelman[1]

 

Background

Macro Laboratories is a major high technology hardware company.  In 1996, it released its very successful Alpha1 machine with its own proprietary Alpha1 operating system.  In 1998, it replaced the Alpha1 machine with its faster and larger Tau model, containing a completely rewritten operating system.  Macro Laboratories is currently developing three new models, each with new versions of the Tau operating system: the Delta, a general purpose machine designed to replace the Tau; the Gamma, a low-cost machine targeting small businesses; and the Epsilon, a high-end machine for specific scientific applications.

 

Although on-time release of all three machines is crucial for Macro Laboratories maintaining its share of these three major markets, a larger than expected number of both hardware and software bugs have put all three projects behind schedule.  Linda Sanchez, Macro Lab's VP for Software Research & Development, has assigned a separate software group to develop new versions of the Tau operating system for each machine.  The Delta and Epsilon groups are located at Macro Lab's Headquarters Campus in Pacific View, Oregon.  The Gamma group is located on the East Coast, at Macro Lab's Springfield Research Campus.

 

Each group is responsible for fixing operating system bugs that are specific to its machine, but the Delta group, at headquarters, has the responsibility to fix all bugs that are carryovers from the Tau machine as well as bugs that are common to all three new machines.

 

 

Message A

 

Date: Mon, 15 Mar 1999 12:01:01 EST

From: Jay.Lee@SPRINGFIELD.MACROLAB.COM

To: Chip.Tseng@HQ.MACROLAB.COM

Subject: Bug Fix #3.99.15.242

 

My main problem these days is getting rude messages from people at HQ.

Here is the problem.  The Springfield Campus group is assigned a large number of bugs that are generic and should not have been assigned to us.  It seems that as soon as someone encounters a bug on a Gamma Project machine they assume that the bug is caused by Gamma Project code.  If a bug is encountered in a common utility such as STOMP-1 or SEEK-2 you should assume it is in common code until proven otherwise.  It is not the Springfield’s group's responsibility to prove that a bug is in common code; it is the owner of the common code to prove that it is machine specific.  If you don't think it works this way, try giving a generic kernel bug to the Epsilon group in HQ. In these cases, a simple comment such as 'I ran SEEK‑2 and STOMP‑1 on a Tau machine and they behave correctly' would have been good enough.

 

The bug report contains complete information about the problem.  Just run 'STOMP‑1' or 'SEEK‑2' on a Gamma Project machine that has more than one disk controller.   The bug report shows examples of both commands on such a machine.   

 

Now, why don't you look at the comment field to see what information I requested.  Then look at Jones'' comment below.  That is the type of information that is useful.  His message even includes the word "please" so at least I know that someone in HQ is capable of politeness. 

 

 

 

Message B

 

Date: Mon, 15 Mar 1999 9:14:01 PST

From: Chip.Tseng@HQ.MACROLAB.COM

To: Jay.Lee@SPRINGFIELD.MACROLAB.COM

Subject: Bug Fix #3.99.15.242

 

> My main problem these days is getting rude messages from people at HQ.

> Here is the problem.  The Springfield Campus group is assigned a large number of

> bugs that are generic and should not have been assigned to us.  It seems that as soon 

> as someone encounters a bug on a Gamma Project machine they assume that the bug is

> caused by Gamma Project code.  If a bug is encountered in a common utility such as

> STOMP-1 or SEEK-2 you should assume it is in common code until proven otherwise.  It is

> not the Springfield’s group's responsibility to prove that a bug is in common code, it is the

> owner of the common code to prove that it is machine specific.  If you don't think it works this

> way, try giving a generic kernel bug to the Epsilon group in HQ. In these cases, a simple comment > such as 'I ran SEEK‑2 and STOMP‑1 on a Tau machine and they behave correctly' would

> have been good enough.

 

So your interest is in unloading as many bug reports

as you can without even doing a cursory investigation.

That's a pretty bad attitude.

 

As for your comment on the Delta Project group, it is just false.

We fix bugs, we don't pass the buck.  The only time we pass

a bug along is when we have done enough investigation to

determine that someone else is more qualified to fix it.

            >

            > The bug report contains complete information

            > about the problem.  Just run 'STOMP‑1' or 'SEEK‑2'

            > on a Gamma Project machine that has more than one disk controller.

            > The bug report shows examples of both commands on such a machine.

 

            > Now, why don't you look at the comment field to see what information I

            > requested.  Then look at Jones' comment below.  That is the type of

 

            > information that is useful.  His message even includes the word "please"

            > so at least I know that someone in HQ is capable of politeness. 

 

I thought the simple statement that it doesn't work on a Gamma Project Machine would have been enough.  I assumed the recipient of the report would have assumed that it works otherwise.  I was wrong.

 

I see that I will have to fill out Gamma Project bug reports under the assumption that I am dealing with idiots, just in case it comes to you.

 

I am polite to competent people.

You don't qualify.

                                   

 

 

Message C

 

Date: Mon, 15 Mar 99 12:22:05 EST

From: Jay.Lee@SPRINGFIELD.MACROLAB.COM

To: Simon.Cohen@SPRINGFIELD.MACROLAB.COM, Rashna.Patel@SPRINGFIELD.MACROLAB.COM Subject: Please put a stop to this

Cc: Tyrone.Smith@HQ.MACROLAB.COM

 

I will not put up the constant name calling and rudeness that comes from HQ.  Please put a stop to this.  This job is stressful enough without having to endure name calling from co‑workers.  The lack of co‑operation from HQ is bad enough that it is a management problem.

 

‑‑Jay Lee

 

 

Message D

 

From Simon.Cohen@SPRINGFIELD.MACROLAB.COM

Mon Mar 15 12:53 EST 1999  

To: Langley.Smith@HQ.MACROLAB.COM, Linda.Sanchez@HQ.MACROLAB.COM

Subject: Choice of Language in Messages

Cc: Tyrone.Smith@HQ.MACROLAB.COM

 

  DO NOT FORWARD.

 

  Linda, Langley:

 

Please see the end of this message for a sample of the level of professionalism demonstrated by Chip Tseng, one of your Senior Engineers.   Apart from the inaccurate take on our attitude toward bugs, it is entirely outside of any bounds of professionalism that I can imagine, especially at a company such as Macro Labs that prides itself on a supportive and professional work environment.

 

We have enough problems, and I don't want to make them worse.  But I now have had a person that has been with my group for close to ten years at Macro Labs come into my office saying he would refuse to work if the job involves personal abuse of the kind you will see below. 

 

I think these EMails sum up the situation much more eloquently than I ever could have.  I'm interested in your reaction to this.  If I ever found out that someone in my group wrote a message like this, that person   would be in considerable career trouble.  And I can assure you that no percentage of my conversation with him would be devoted to why or whether his action was justified.

 

There are problems, and we need to work to resolve them. There are clearly areas of division of labor that need to be clarified. But I don't think we need to allow this in the interim.

  ‑‑Simon

 

Message E

 

Date: Mon, 15 Mar 1999 12:04:09 PST

From: Linda.Sanchez@HQ.MACROLAB.COM

To: Simon.Cohen@SPRINGFIELD.MACROLAB.COM

Subject: Re: Choice of Language in Messages

Cc: Tyrone.Smith@HQ.MACROLAB.COM ,Langley.Smith@HQ.MACROLAB.COM

 

Chip Tseng is not in serious career trouble.  He has done more for the quality of the 2.0 releases than any single person that I know.  When I was running the Alpha project, my organization was certainly reprimanded by Chip Tseng. However, the engineers have incredible respect for him. 

 

I am very concerned about the flare up the past week.  My EMAIL is flooded.  People at both sites are acting inappropriately in my mind. I look to you and Langley Smith to work together, set the tone and get your two organizations focused.  It is critical to get these two co-dependent projects back on track.  From my perspective, your work procedures are not complete.

 

If I need to meet with both teams I will be glad to do so.  First, I need you and Langley Smith to work out a plan ASAP and get the organizations back on track.  We have our top people at both sites seriously spun up.  Please help us get this project back on track.

 

If you need/want to discuss some of these issues over the phone, I'll be glad to.  Set up some time with my assistant, David Dante.

 

‑‑Linda Sanchez

 

 

 

 

 

 

© 1999, 2000 Leslie C. Perelman

all rights reserved


 


 

[1] Although based on an actual incident, this case study has been rewritten by the author with assistance from Alexander d’Arbeloff.  All references to specific individuals and organizations have been changed, and, consequently, any references to actual persons or organizations are coincidental.