毛主席教导我们说：“阶级斗争要年年讲，月月讲。” 在美国公司里也讲斗争，政治斗争。不仅要年年讲，月月讲，而且还要天天讲。

我刚开始在i2工作时，作软件开发。那时，工作很紧张。Release一个接着一个。我在一台计算机上同时要保持两个开发环境，一个环境用于下一个 release的开发，另外一个用于现在release的bug fix。尽管很忙，但看着自己的工作成绩，还是感觉很充实。一个人从早干到晚，几乎就不出办公楼。今年夏天不在i2工作了。感觉到达拉斯的七八月份特别热。跟别人一说，别人居然说今年夏天不算热的。这让我感到特别奇怪。前面四个夏天我都是在达拉斯过的，为什么我以前没感到热呢？直到有一天我突然明白过来，我以前在i2，太专心于工作了，根本没功夫注意到天气的冷热。这让我不禁又感慨一番。

我后来开始参加管理工作，发现管理工作同开发太不一样了。开发工作的成绩完全取决于你自己。你干得好，马上就能看到成绩。管理就不一样。你的部门的成绩的好坏不完全取决于你的部门。你需要别的部门的配合才能完成你的工作。但问题往往就出现在这里。RCP的release十分频繁，各个部门需要密切协调才能保证产品在规定的时间内交付。RCP的各个部门经常因为协调的问题进行争吵。有的部门的工作必须等到另一个部门的工作完成之后才能进行。有时候，眼看着 release的时间就要到了，但前面的部门的工作要拖延，后面的部门的manager就开始着急了。於是在管理人员会议上就开始逼着前面部门的 manager赶紧完成他们的工作。争吵就这样开始了。开发部门同开发部门吵，开发部门同产品管理部门吵，但吵得最多的还是杜珏带领的QA同各开发部门的争吵。QA是每个release的最后阶段，哪个部门的拖延都会直接影响到QA的工作，所以在RCP的管理人员的会议上，杜珏经常是争论的一方。我所在的开发部门作的软件的质量比较好。出现的bug少。即使QA发现bug，我们也很快就修改好。所以我们的两个部门间的矛盾较少。

RCP管理会议上的大部分的争吵是有建设性的。大家的目的都是为了工作，所以即使有时争论激烈，但一点儿也不影响大家的工作关系。但有的manager没有基本的品德。有的十分阴险，有的厚颜无耻，能够当面撒谎。有一个manager公然说：“在i2工作，就是要有点儿street smart."

我们部门曾经同加拿大的一个开发部门合作，共同作一个release。那个部门的工作必须先完成，我们才能开始我们的工作。那个部门管理得不好。开发人员的素质不错，但manager的管理的能力不行，所以经常拖延。在到他们应该完成的那天，我在RCP管理人员的会议上特别追问那个manager，问他们是否完成了他们的工作。那个manager肯定地说他们完成了所有的工作。等到会议后，我问我们的开发人员，发现他们的source code根本没在ClearCase里面。

在我接触过的所有的i2的manager当中，最厚颜无耻的莫过於BH。BH是在RCP的全盛时期从别的部门转过来的。刚开始时，他同时管几个部门，包括我后来接管的PSR小组。但后来他管的部门越来越少。在被i2裁掉的时候，他只管一个部门。尽管如此，那个小组的问题还是很多。

BH的各方面的能力都差。他是软件开发的manager，但他的专业知识极差。在一次设计讨论的会议上，他居然问MCV(Model, View, Control)代表什么。这让我大吃一惊。BH的专业能力不行，管理能力不行，为人处世的能力也差。他与同级同事及老板的关系不好。在RCP管理人员的会议上，经常会干一些愚蠢的事，进一步破坏他与别人的关系。有一次，他居然同我们部门的VP当众争论起来。象他这样的人居然能够躲过i2的前几次的裁员，这也算是个奇迹。

导致BH的最后被裁掉的原因恐怕是他的最严重的一次撒谎。那一次，我们马上要给一个Fortune 500的客户一个release。当时Nike的事件已经发生，所以大家都特别小心。产品交付的时间马上就要到了。但QA还是不断地发现bug。RCP的 manager们都非常紧张。我们的VP也开始参加每天的War Room会议。在一天的War Room会议上，突然发现一个bug居然有两天了，还是没被修改。这个bug是BH开发部门负责的。BH说QA根本就没有通知他们。杜珏说早就告诉了BH 部门的某个开发人员。BH坚决否认。於是两人就争论起来。在场的VP开始发火了。不客气地打断他们，说道：“One of you is lying." 当场打电话找到发现这个bug的QA，把电话的speaker打开，让那人讲事情的经过。真实的情况当然是证明杜珏是对的。BH只好讪讪地说：“我回去看看是怎么一回事儿。”在i2的下一次的裁员的名单上，BH就榜上有名了。