我从一个做了将近二十年的individual contributor突然转成了一个低层的管理人员（虽然职称上还不是经理），在工作中做了很长时间的挣扎，大概花了一年多的时间，才找到了自己的方向。虽然我还是管理者中的菜鸟，但是我希望通过我的分享，让大家感受到一个管理者是从哪些角度看问题的，可能会对自己有所帮助。因为有点长，要分成两部分写。
要讲我如何工作，还要先说说我们组的组织形式。我们大组开发和维护公司的管理软件，一共有四十多人，包括BA， Developer，DBA，系统管理员等，分属不同的小组，每个组设一个lead。我是developer组的lead。我们同时会做好几个项目，人员都是临时组成的。在一个项目上，一个senior BA做project lead，一个senior developer做technical lead，领导其他的developer。如果这个senior developer有管理项目的能力的话，还可以兼做project lead，就像我最早几章讲到的我曾是technical lead兼project lead。一个项目完成了，上面的人员就会被打散，新起的项目又会有不同的人。这样的组织形式很像我以前做过的一个consulting公司，非常锻炼人。
这种组织形式让senior developer有很大的成长空间，他们直接对项目的技术质量负责，那么lead developer的职责定义就很模糊。做得不好的话，就变成了developer加上做一些one-on-one之类的杂事，外加年终总评。这就是为什么我做项目的technical lead的时候，却出现了我的lead来我的项目上做developer的怪事。那时候对我来说，我的lead除了每两个星期和我做一次one-on-one，和一年一次的年终总结，他的存在对我的工作没有任何影响，这也是我在文章中没有怎么提到他的原因。他做了多年的lead也没有提成经理，最后去了别的组做了senior developer。
我当初申请做lead，就没打算做一个职称变了，角色却没变的lead。可是这个lead应该怎么做，却没有人告诉我。我的直接老板也没有对我提出过具体期望。一开始的半年左右，我是完全陷入了一种混乱状态，要应付各种人的各种需要。BA组的lead好心地告诉我，要了解每个人的知识和能力，这样老板要确定什么人做什么项目的时候，你就能提出合适的建议。
我接受了他的建议，在one-on-one的时候就一个个问组员以前他们都做过哪些项目，对系统的哪些部分了解得多，然后都仔细地记下来。可能有人会有疑问，你在这个组这么多年，怎么对谁会什么都不了解。实际情况是，我过去的精力都花在做项目上了，做过同一个项目的人我会了解，其他的就不太了解了。我把组员会的东西都做了笔记，可是并没有在头脑中留下太多的印象。如果有人找我推荐组员帮他们解决某些问题，我还是得把我的笔记一条条看，看看谁会。同时还要知道谁有时间，是不是在忙什么项目，分身无术。一个看似简单的用人问题，我却要花些时间想。当然我还有一个私心，就是想如果我每次都要问组员谁能做的时候，我是不是显得太无能了。不过有时候信息不全，还是要这样做的。
在面对全新工作的混乱状态中，我还是做了两件我很满意的事情。一件事是我决定减轻senior developer对于系统维护方面的负担。我们的senior developer不仅在项目上管技术，还要每天处理很多production的问题，有时候甚至占到了他们将近一半的时间。于是在和老板沟通之后，我把每个senior developer要维护的方面都加了几个非senior developer，等senior把他们教会后，他们就可以把senior的负担分走很多。我自己原来负责的方面，也都慢慢交出去了。这样这些senior，就可以把大部分精力放在做项目上了，而且非senior也可以学到更多的东西。我觉得这是一个双赢的结果。
第二件事我觉得做得好的，是我要求组员们要互相做code review。这个在很多IT公司很普遍的事情，我们组却做得很少。我在这个组这些年里做的code review，两只手都能数得过来。是什么促使我做了这个决定呢。一是因为有三个新组员问过我为什么我们不做code review，二是我参加的一个经理级的培训，听到一个customer service的经理讲他们培训新员工时一个很有效的方法，就是听这个员工回答用户电话的录音。根据录音给员工提出改进意见。我知道我们分公司的customer service非常有名，很多用户用我们的产品很多年，很大原因是我们的customer service极好。
这个经验对我很有启发。我想我们程序员的产品就是他的程序，如果有其他程序员对他的程序进行品评，特别是对一个新程序员来说，对他的帮助肯定很大很直接。很多senior写程序的好的理念，也会在这个过程中灌输给新人。有了这个想法之后，我就要求项目上的senior developer要review其他人的程序，其他非senior也可以互相review，这样大家对这个项目也会更了解。
领导老美有一个好处就是，他们绝对服从领导。大家二话没说，就开始了review。一开始没有好的工具，我们就用email。后来一个developer把她在以前公司用的软件介绍给我们，我们使用了几个月的评估版，觉得非常好用。我就找老板商量，花几千块钱把这个软件买下来。老板非常支持，于是不久之后，我们用上了正版。
开始了review，各种问题又随之而来。最开始大家还在程序的format上争论，我就想统一format，不要在这个上面花时间。我上网找到了一个format标准，和大家讨论。意见一致后，老板又支持我们专门做了一个项目，把这个标准用工具实现，并且把所有程序的format都标准化了。
很快到了写组员的年终总评的时候，我写得相当痛苦。因为我没有跟进他们做的项目，从one-on-one听来的也印象不深，只能根据其他人对他们的反馈来琢磨他们做得怎么样。老美有一个特点，写反馈的时候都只写好话，结果大家都差不多，很难分出谁更好。我花了很多时间读这些反馈，试图从些微的用词区别来分出好和更好。最后我感觉还是不太理想，可是到了年底，大家都休假了，我也没办法再找人从头仔细问。
第一年的管理工作就在各种忙乱和不满意中过去了。
