一个Team出去吃饭，或者出去旅游的时候，你是得意忘形的放开手脚去玩吗？甚至脱离团队和要好的朋友去逛吗？不要这个样子。余世维在《经理人常犯的11个错误》的演讲中曾经说过，出去Team building，对于员工来说是休息，而对于经理来说是工作。的确，你要清楚资本家为什么会出钱让员工去做这些和工作看起来无关的事情？为什么要大家一起出去而不是每人发钱自己去玩？当然是要增加团队的凝聚力和归属感，为共同合作奠定基础。既然对于经理来讲是工作，难道你不应该有责任辅助你的经理做好工作吗？在大家一起吃饭的时候，如果冷场，积极的起一个话题吧；在经理提出玩一个团队游戏的时候，率先支持，主动去做吧；在外出旅游的时候，帮助你的经理订餐馆，清点人数，摄影照相吧；当爬到山峰，或者年会表演节目的时候，喊出增加团队凝聚力和影响力的口号吧；在活动结束后，整理资料，相片，发出email来进一步增加活动的效果吧。这样你是有组织能力的，辅助经理成功的，有良好影响力的，也是热爱团队的。

　　这里提到了团队聚餐中的话题问题，这里顺便提一下，当然根据不同的Team的氛围以及当时的情况而定，话题的优先级依次如下：

　　项目话题：如进度，难点，后面还会提到，学会喊累，喊忙，这是一个比较好的机会。当然此话题比较适合加班或者中午时的团队聚餐，不太适合旅游时候的团队聚餐。此话题可表明你对项目的关心。

　　技术话题：比如语言排名，那家公司被收购了，平台之间的差异等等。此话题可说明你对技术无限热爱。

　　员工生活话题：比如干什么了，介绍女朋友，结婚，孩子教育等，当然以当事人意愿为准，不要太当真。此话题可说明你关心同事。

　　娱乐话题：比如看什么电影，娱乐圈出来什么事情等，这是话题，也是保险的话题。

　　员工敏感话题：比如非议其他Team，或者美国团队等，此类话题好不要涉及，背后议人不太好。

　　公司敏感话题：如有的Team裁员，减薪，福利下降等，此话题千万不要提及，这是领导层想尽力遮盖的问题，甚至不在项目经理的权利范围之内。涉及此类话题将给人以你是一个不可托付大任的人。

　　后，如果你在学校中是演艺明星或者体育明星，那么年会的表演以及团队之间的比赛也不是你表现英雄主义的地方，而是体现团队意识的地方，也是交流沟通的好机会。所以不妨在节目中介绍一下自己团队的产品；不妨在角色设定的时候劝说core team的人加入扮演一个牛人角色(欢乐可以一定程度上冲淡马屁味道)；不妨申请印有团队logo的运动衣；不妨在运功过后和高层一同边走边聊(比平时冲到高层办公室里面好的多的机会)；不妨去敬HR一杯酒，被她们多灌几杯(HR的办公室是个敏感区，平时很难交流感情啊)；不妨去维护机房的团队那里敬酒以感谢他们的工作，去前台那里敬酒以夸赞她们的服装，发型等(他们对你来说真的很重要，想想几百人的团队，前台和运维都只有两三个人，还是那话，当供需相差很大的时候，价格都会越来越高)。这将使你成为一个受欢迎的人。

(5) 适当的增加影响力

　　做一个好的基层程序员，除了完成自己的本职工作以外，也需不断增加自己的影响力，这既是你的品牌，也是日后加薪升职不可缺少的因素。

　　增加影响力主要有以下几种方式：

　　在工作中，如果完成了一定的功能，或者测试有了详细的报告，可发邮件给领导并cc整个Team，让领导知道你的付出，和同事分享你的喜悦，让众人知道你的亮点。邮件或者报告要在开头做精炼的总结，使得大部分人能够尽快的了解结果，具体细节可放在后面，供同模块的员工详细查阅。千万不要默认你的上司和其他人都显而易见的知道你完成了什么，这也可能是很多人觉得怀才不遇，难遇明主的原因吧。台湾作家黄明坚有一个形象的比喻：“做完蛋糕要记得裱花。有很多做好的蛋糕，因为看起来不够漂亮，所以卖不出去。但是在上面涂满奶油，裱上美丽的花朵，人们自然会喜欢来买。”

　　在各类的会议中，如上面所说，事先准备问题，合理提出建议，适时提供证据，都是在同事，领导，以及外国人面前展现自己的机会。

　　有时候美国有或管理或技术的老大来中国，都会召开all hands，这是一个不可多得的在整个公司面前展现自己的机会。而在外企，程序员的竞争力大约包括对产品的把握，对技术的把握和对英语的把握等能力。all handls也是展现这三种能力的好地方。也许你会发现这样的事实，在all hands上英语流利的提问者们，提出问题的目的也许并不是为了想弄明白什么，而是为了展现什么。他们大多是这样问的："As what you side A， but actually what we did in our project is B， so how/what/when C"，你会发现，A和B会说的很具体，而C很抽象，显然A是为了展现产品把握能力(你讲的我都听懂了)，B是为了展现技术把握的能力(我们采取了什么样的技术)，整篇都用英语表达自然展现了英语的能力，后问一个很Open的问题C，总不能问老大个很难的问题吧。

　　tech talk：当有了一定的技术积累，tech talk是一个很好的展现技术实力的平台，毕竟程序员是吃技术这碗饭的，所以良好的技术口碑对初的升职至关重要。tech talk所讲的对象一般不是同项目的员工，因而难度要适当的把握，太简单则不足以体现你的技术实力，太难则大家会听的云里雾里，不能真正了解你的价值。在做tech talk的时候，好一开始有一个整体的流程或者框架的介绍，以使得听众不会在途中迷路。一般有一个规律，是在前面几个slides的问题是多的，大家总能够提出各种各样的问题，所以开始的几页，一定要是你熟悉的，有价值的，然而随着信息量的增大，后面几乎提不出什么问题来了，到演讲后，一般也只能提出一些open question了，一般可以通过三个阶段轻松回答，其一，that is a good question，其二，it really depends，其三，I'd like to give an example。

　　demo：在很多施行迭代开发的项目管理的公司里，一个阶段是会有一个demo的。很多程序员重代码，而轻demo，明明实现的非常优雅的功能，却懒得花时间生动的demo出来，中国有句古话：六十四拜都拜了，差后一哆嗦，多对不起你前面没黑没夜的工作啊。demo是应该好好准备的，应该有一个详细的demo流程，先录入什么数据，然后如何操作，后应该看到什么等等。然而demo是容易失败的，似乎成为一个难以规避的定律，即无论原来demo如何准备，临阵总会有意想不到的结果，大概因为看demo的人可能会提出奇怪的尝试需求，而可能正是程序员没有考虑过的边界。所以demo中，应该事先将良好的过程录制下来，以防止真实demo过程中有差错，造成功亏一篑，至少可以证明原来是好的。在demo中一定要用近似真实的数据，如输入人名，用真实身边的员工姓名，输入日期用当天的真实日期，千万不要用aaa， bbb， 123456此类的数据，既不美观，也容易出问题。而且在demo的过程中，应该严格按照已经准备好的流程走，当完全走完流程后，方才可以处理现场提出的各种尝试，可保证能够完成demo任务。

　　帮助他人：在不耽误自己工作的情况下帮助他人解决技术难题，是比tech talk和demo更能够体现技术实力的地方，并会积累下人脉，当众望所归的时候，你的升职也仅仅是时间和名额问题了。举个相似的例子，tech talk好比是保健医生，只不过是给你宣扬养生之道，而解决技术难题如同主治医师，可以使你药到病除。很显然，如果一个人如果能够很好的按照保健医生的养生之道去做，很少会去找主治医师去看病了。然而主治医师却比保健医生更受欢迎，一方面因为相对重要的事情，人们多会更重视紧急的事情，一方面可能因为只有在逆境，出现问题的时候，人们才会虚心接受他人的意见。试想听tech talk的人们，如同6000点的股市中的股民，多抱有"你懂，我可能比你还懂"的想法，而出现了问题的人们，便如跌至2000点股市的股民，才会虚心向专家请教，并对给出的方案五体投地了。而且此点满足，不忙的时候，主动帮助他人——让上司有效!

　　培训新人：有时候公司会招来一些学校来的实习生，一年一度也会招很多应届毕业生。当然一般公司都会有各种的培训，然而一旦进入团队的时候，如何更快的上手项目，仍然需要一个过程，如果能有老员工指导一二，将会轻松很多。在项目比较紧的情况下，很多老员工不愿意培训新人，万事开头难，起步总是相对缓慢的，害怕因此而耽误进度。当然，以耽误自己的工作换来对新人的培训我也是不赞成的，这也是后面所说的要给自己留buffer的原因所在。但我需要指出的是，给一个饥饿的人一个烧饼要比其成为千万富翁后给一百万更加让人感恩。人的眼光应该长远一些，无论如何都不要轻视一个年轻人，因为你不知道其将来会是什么样子。有的人，年纪大，level高，但是基本可以看出其一辈子的轨迹了，有的人年纪轻，level低，却可能前途无量，你永远不能把握将来谁会是你的贵人。

　　在增加的影响力的前面，我加了一个形容词——适当。要有和你的level相匹配的影响力，小心功高盖主啊。外国人有时候会强调leadership without authority，然而如果你果真这样做了，多半会招来同事的敌意(你凭什么指手画脚的啊)，也可能会招来你的lead心中的隔阂(没有authority你都能够lead啦，给你authoriy还不反了天了，你lead，那我干嘛)，所以还是不在其位，不谋其政的好。

(6) 给别人光环

　　当同事完成一项功能或修改完一个Bug的时候，你是否给过真诚的赞誉，帮其增加上述的影响力？

　　当同事帮助你解决了问题或者提出了的方案，你是否公开表示感谢，让群众和领导都知晓？

　　当领导问及你做的模块的时候，你是否有意隐瞒了他人的功劳而突出自己的贡献？

当会议的时候，你是否会处心积虑的故意反对竞争对手的方案，虽然你觉得其实这真的是个好方案？

　　当发现其他人的Bug，Code reivew的时候发现他人的设计缺陷，你是否幸灾乐祸的大声疾呼，唯恐他人和领导不知？

　　你是否在同事，领导，HR的面前非议他人，嘲笑他人的设计，褒贬他人的缺陷，鄙视他人的技术，虽然的确你是此方面的大拿？

　　当你有幸获得一份荣誉的时候，你是否先谢(公司)，再谢政府(团队)，再谢领导，再谢同事？

　　给别人光环吧，别人也会给你光环。

　　一个只顾自己头上光环的人，以及一个别人给了光环而不知回报的人，终都会孤立无援，难以开展工作，是涸泽而渔的做法。