在Google做技术经理带团队，很锻炼人！

另一方面，工程师们"极客"和"宅"的一面常常在外人难以注意的工作细节里表露无遗——这里有十数年如一日致力于优化编译器的语言高手，有设计最好的代码审读系统的工具专家，有亲自动手实现软硬件原型的技术总监，有坚持为地球上每一种人类语言提供输入输出解决方案的国际化团队……

这是心态的差别，或者说，是技术境界的差别，烙在 Google 工程师的基因里，旁人想学也未必学得到。

3、"管理"二字的意义

有时候工程师很难管理，因为大多数人都想法新、主意多、眼光高、个性强。在 Google，有时候工程师也很容易管理，只要鼓励他们把一件看似普通的事儿做出世界级的水准，他们自己就有足够优秀的执行力，用不着督促。

在 Google 做技术经理带团队，和我以前在其他公司带团队，完全是两码事。这也许和技术团队的平均水平有关，但根本还是管理境界的问题。

记得以前在别的公司，花大力气搞开发流程管理，现在想想，大多是繁文缛节，程式化，教条化，最极端的像 ISO9000 之类的流程认证，弄得所有人筋疲力尽，效果未必有多好。

到了 Google，发现一个秘诀，再多的规章制度，再多的流程，不如一套好用的工具来得有效。比如 Code Style 和 Code Review，以前能把技术经理烦死，三令五申也执行不下去，顶多三天热度之后，大家就阳奉阴违了。在 Google，这件事不完全是个制度的问题。

刚进来的工程师没有过 Readability Review，他就没法方便地自主提交代码，这是代码管理工具设置的硬性限制。这直接把工程师们送到评审委员会那里接受"再教育"，没错，真的是"再教育"，连 Python 之父 Guido van Rossum 也花了挺大力气才通过了 Python 语言代码的 Readability Review。

接下来，提交新代码前，各种静态、动态检查工具自动运行，帮你报出一系列风格错误、编译错误、单元测试错误和简单的逻辑错误，你得先依着工具的提示，把这些低级别错误改一遍，然后才进入 Peer Review 的环节。整个 Code Review 都在非常方便的网页工具里完成，写代码的和审阅代码的人可以方便地交互、讨论，甚至在线修改代码。

工具的"强制性"保证了制度的执行，工具的"便捷性"最大程度减轻了工程师执行制度的负担，二者相辅相成。当然，Google 内部也不乏对制度敷衍了事的，但相对其他公司，Google 的确做得更好些。

说到管理，在 Google 带技术团队的其实都苦哈哈的。我就先后两次把团队交给别人带，自己乐得去做些单纯的代码工作。道理很简单，头衔是 Manager，可你没法高高在上指手画脚，Google 最好的团队带头人都是冲在第一线带着大家一起干，除了主动包揽大家不想干的脏活、累活、杂活之外，还要做管理者必须的非技术工作，比如给每个人写评语、定奖金，帮每个人申请升职，跟心理负担重的谈心……

一个人做两份工，吃力不讨好，对团队成员的晋升也没有决定权（这事儿也挺神的），这种 Manager 的活儿，谁愿意干谁干去，我是不大喜欢干的。不过，不喜欢归不喜欢，Google 这种挺不一样的管理既显着混乱无序，又运行良好，确实很神奇。

严格地说，聪明人在一起，只需要激励，不需要管理，Google 的办法主要也是强调这一点。

必须坦白，我加入 Google 时，工程师才三千人上下，无序管理、自发管理、扁平管理占主流。Google 越来越大以后，大公司病也如约而至。流程越来越复杂，层级越来越多，职权重叠和模糊越来越严重，不同团队之间管理风格的差异也越来越大。

但即便如此，Google 基因里那种蔑视陈规、抵制办公室政治、抗拒繁文缛节的管理风格还是能在许多团队带头人的身上找到——这是 Google 肌体里的健康因素，活力因子，弥足珍贵。

顺便说一句，最近中文圈子热传不写代码/不会写代码的 CTO 一事，许多 Google 工程师出身的 CEO/CTO 都在朋友圈里晒自己写的代码，以表明态度。我自己对技术管理者写不写代码没啥倾向，写不写都可以是好的管理者，但如果"不会写代码"还以此为荣，就完全没法接受，这个是底线。

我在 Google 面试了不少 Manager 和 Director 的候选人，都考过对方写代码或者至少讨论一段代码的能力——不是要他一定在管理过程中写代码，而是怕他和 Google 工程师没法交流，和 Google 技术基因没法共存。

在 Google 做技术管理，学不到啥成文的规矩，能学到的其实主要靠"悟"。

4、看待职业生涯的心态

很多人来 Google 还是奔着一份优越的薪资待遇来的。所以，这里只谈我自己。

有一种