A某开始整日搭着PM们的顺风车， 在外面跑。 Gathering requirements, solutioning， estimating effort, briefing the work... 这些本来属于pre-sales 的工作， 由于solution architect的紧缺，慢慢地落在了A某的头上，而A某原来的一些development和maintenance的工作就慢慢地落到了其他 skill或者attitude 比较好的人的头上。为了用比较通俗的语言来阐述这个比较复杂的问题，A某将使用自己研究多年的 “小强与小乖“ 法则来解释这个问题。 当小强和小乖都处在正常负荷的工作强度之下，如果你再给他们同时增加等量的additional压力，你将会清楚地发现，小乖将继续以相同地进度工作， 并把每日的OT时间拉长；而小强将立刻出现反弹， 具体表现在气急烦躁， 时常请假，非暴力不合作， 工作经常出错等等。 。。

当碰到这样的“小强”时，经验不足的A某在briefing work的时候第一次采取了低声下气的做法，由于briefing通常是在口头下进行的，几次以后，发现小强根本没有按照A某讲的那样做，并常常地发表一些高见。 后来经过高人指点， A某采用了大家经常使用的"CC PM"的方法， 也就是在做完briefing之后， 发一个follow up email: Dear 小强，As spoken/discussion, please ....目的就是说，我刚才是这么讲的，你怎么做就是你的问题了。这个方法还真有小，经过几天的"CC PM" 之后，大家惊人地发现，A某严肃的面孔上露出了少有的笑容，胃口开了，吃饭也香了。。。

然而， 好景不长， 一个月之后的某一天，不知怎么的， 小强和PM扛上了。听说是project出了个低级却很严重的问题，PM去讲小强的时候，小强说了一些压抑已久的比较难听的话。。。后来，PM吃饭的时候跟我谈，平时能不能看着小强， 让他不要出错。 我说，其实小强的skill挺好的，只是有时候太粗心了。 以A某高见, 像他这样的性格, 我跟他处在同一个level， 我讲的他不一定会听得进去， 建议叫XXX (一个资格比较老solution architect) 跟他讲比较好。

再后来的事情我想大家也应该猜到了，就是在半年一次的performance review中，A某由director提名再次意外地晋级。。。我不知道是不是PM那时理解错了我关于“同一个level" 的那句话, 那一次，整个部门只拿到两个promote的名额； 那一次，A某正好碰巧完成了J2EE和mobile的architect认证；那一次，蔚蓝的天空中依旧漂浮着朵朵白云。。。

P.S. 这里顺便提一下A某关于各种认证的看法： 以A某高见，当没人看得上你的时候，证书也许只是一张废纸， however, 当有人想要提拔你的时候，everything counts...