首先我们明确技术团队是指做技术的团队，而不是仅限于技术小组。这样的话，技术团队可大可小，比如说，我带过6个人的技术小组，现在带将近40人的研测团队，我的老大负责整个九游（现在逼格高了，叫做“阿里游戏”）的技术团队，人员规模是几百号人，大点公司的CTO，技术团队可能是上千上万人。
不同规模的团队，负责人的做法差别很大，以下回答部分是参考我的经历，部分是我自己推测的，如果大家在实际应用中应用这些技巧遇到问题，别打我哈 ：）
- 【5 ~ 10人团队】
这就是最小的技术团队，一般来说就是负责某个大业务系统里面的一个子业务，或者某个大平台下的子系统。
这个问题
1）负责人一定要技术强，业务熟悉，不求组内最强，但至少也要是前三的。
有的人看到这个说法后可能不以为然：“不是说要招聘最牛的人然后授权么”？
这句话本身没错，但用在这个团队规模就是错误的，原因是什么呢？
首先，大部分公司都有人力资源控制的，本来团队人员就不够，你还要区分一个做管理的，一个技术核心，浪费钱啊
其次，就算你招聘到了，这个规模的团队大部分事务都是具体的技术和业务细节，如果团队负责人只是负责转发邮件、组织会议、有问题就说“你们找XXX吧”、对外不参与业务讨论、也不参与方案讨论，嘿嘿，你当组内人员是傻瓜呀，你当核心人员是傻瓜呀，没有团队成员的信任，哪里来的领导力 ？
第三，就算大家表面上服你的领导（层级在那里，不得不服），但如果有一天核心走了怎么办？要知道招聘一个牛逼的人，可能半年1年都招不到，核心对你不爽，一走了之，你啥都不懂，其他人也一般，这个团队就陷入无序甚至瘫痪了。
有的朋友可能会说，那我招聘2个牛逼的人呀！听起来很美好，招聘过的人就知道这很难，面试了几十上百个，遇到想要的牛人就那么一两个，结果因为要价太高，公司还给不起 ：（
还有一个现实的问题，技术负责人自己技术不强，怎么能够找到牛逼的技术核心人员 ？
2）最重要的是培养下属
都提到了业务，团队，但以我的实际经验来看，当团队处于这个规模的时候，团队负责人对业务的控制力是比较弱的，更多的时候业务是由外部驱动的，比如说由产品人员主要负责业务规划方向，或者由大业务决定子业务，技术负责人最多建议，不太可能把控；
团队方面也是一样，技术负责人应该去争取团队利益，但能否争取得到，更多的时候看再上一层如何决策和平衡。
所以这个级别的技术负责人的主要职责是带领团队将安排的业务做好，并且手里并没有太多资源，这种情况下，组内人员能够从负责人那里得到什么利益呢？ 我觉得最主要的利益就是跟着负责人学到了东西，得到了成长。这其实又回到了我说的第一点，技术负责人自己要强，否则别人怎么从你这里学东西呢 ？
分享我之前的老大给我们传授的一个经验：30%做管理，70%做技术，按照这个标准来衡量自己或者你的leader，管理投入太多可能成了项目经理角色，管理投入太少可能整个团队就运转不畅。
- 【10 ~ 50人技术团队】
10 ~ 50人的技术团队，基本上就不是单个子系统或者子业务了，更多是一组相关业务，甚至就是一个完整的业务了，要知道大部分创业公司技术人员可能也就20 ~ 30人而已。
这个规模的团队的技术负责人，做法和10人以下团队负责人的做法就差异很大了，为什么呢？
主要原因是因为：整个团队分成多个小组。一般一个小组大约就是10人以内（贝索斯推崇的理想团队符合“2个披萨原理”，即一个团队吃两个披萨应该能够吃饱，否则团队就太大了）。
分成多个小组对技术负责人管理上的要求有和变化呢 ？
首先，你不可能关注每个人了。举个最简单的例子：季度沟通的时候，假设每个人30分钟，如果你每个人都沟通一下，50人的团队就要25小时，这意味着你基本上一周啥都不干就只能沟通了。
其次，你不可能参与每个系统的开发了。这个显而易见吧，50人的团队，各种系统少说7、8个，多的十几个都是正常的，你怎么可能去参与具体版本的开发呢 ？
第三，小组间的冲突协调现在需要你来处理了。比如说，A组说我们要这样做，B组说A组这样不行，那最后怎么办？ 就只能靠你来协调了。
第四，需要关注整体的情况。单个小组的质量和效率或者士气等情况对你来说已经不是最关键的，整个团队整体的情况才是你关注的重点。
第五，业务好多，你不可能每个都熟悉。每个小组负责1 ~2 个子业务，整体团队的子业务少则7/8个，多则10多个，你全部熟悉所有业务，这几乎是不可能的。
以上这些情况的变化，技术负责人的管理方式也需要采取不同的手段。
1）划分合理的组织结构
将团队分为多少个小组，每个小组负责什么业务，看起来无关痛痒，实际上是整个团队运作的关键。有一个著名的康威定律（不是电视机），大意就是：产品就是组织结构的体现。
具体如何划分，和公司的文化、传统、规范等相关，难以给出一个统一的标准。前面提到的贝索斯的2个披萨理论可以用于指导团队规模，我推荐团队规模符合著名的7+-2原则，即5 ~ 9个人，因为一个小组负责人关注的人数就是这个规模，太多了关注不过来，太少了团队做不了什么事情。
2）培养小组的技术负责人
包括技术培养、做事方式培养、管理能力培养等，具体怎么培养呢？ 你做小组技术负责人时怎么做的就怎么培养吧。
通过培养小组的技术负责人，然后由他们来管理和领导具体的每个人。
3）制定整体的流程和规范
整个团队的流程、规范（代码规范、发布规范、评审规范、测试规范、部署规范、灰度规范等）需要明确下来，各小组按照统一的规范和流程操作，尽量避免分歧和争议。通过规范和流程的约束，让整个团队运转更加顺畅。
4）把控团队技术发展和提升方向
这个时候技术负责人已经有一定的资源和权力，能够主导一些事情了，技术发展方向和提升方向就是最重要的需要技术负责人把控的。为何这个事情不能由小组技术负责人完成呢？一是因为小组的业务开发压力都是比较重的，没有太多时间来考虑和实施；二是因为小组技术负责人视野和信息毕竟有限，不一定能够识别出来。
举个我现在做的事情为例：整个系统的结构已经很不合理，但各个小组技术负责人都不知道该怎么做，如何协调资源，我接手后跟老大沟通，跟产品沟通，跟运营沟通，然后推动系统架构解耦的事情。
这个时候技术负责人能够掌握薪酬激励等资源么？ 看公司情况而定，我了解是大部分情况下还不会掌握这些资源，但是有一定的权力去在团队范围内分配资源。
- 【50 ~ 500 ~ 5000 ~ 50000技术团队】
这种情况我还没有经历，一般到了这个级别，都是总监、总裁、CTO级别了。我觉得之前的做法也都不适应了，我想了一下，这个级别的技术负责人，可能主要是负责如下几个事情了：
1）技术文化建立
文化看起来是个虚无缥缈的东西，但其实大部分人都能够明显的感觉到。例如：
你是要高薪招聘牛逼的人才，还是低薪招聘廉价人员？
你是要决定让技术人员完不成任务就加班，还是要决定我们要少加班，尽量做有价值的事情？
你是要鼓励大家技术提升，还是就当技术人员是苦力，女人当男人用，男人当牲口用 ？
当业务与技术冲突的时候，你是鼓励技术为业务让步，还是坚持技术底线 ？
你是准备培养开放自主的氛围，还是培养等级森严的制度？
。。。。。。。。。。。。。。。。。。。。。。
这些其实都是文化的一部分，而且为何到了这个时候技术负责人可以做这些事情了呢？ 简单来说就是技术负责人已经掌握了相关的资源和权力了。
2）公司技术平台的建立
当公司发展壮大后，业务肯定是越来越多，但这些业务所需要的很多技术都是通用的，例如：运维平台、数据库容灾系统、网络跨机房建设等，这些事情跨多个部门和业务线，除非级别够高，一般人都无法推动这样的事情落地。具体的案例可以参考阿里和腾讯的中间件或者平台系统。
怎么建？ 其实互联网技术发展到现在已经基本上形成比较固定的模式了，照猫画虎，依样画葫芦就差不多了，有兴趣的可以看看我的专栏：专栏：BAT解密：互联网技术发展之路
最后，细心的朋友可能看到我一直都没有提到技术负责人要精通业务这个点。这可能也是大家有争议的地方，有的人会认为技术负责人最后都要懂业务，甚至把握业务发展方向。以我的理解和经历来看，技术负责人在业务这部分的积累本来就少，术业有专攻，技术负责人的业务能力超越产品和运营，几乎是不太可能的事情，术业有专攻。当然，凡事都有例外，我之前的老大就是通才，而且每个都做的很好。但我相信大部分人资质和水平应该是达不到这样的程度的。链接：https://www.zhihu.com/question/39421456/answer/82035129
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
首先我们明确技术团队是指做技术的团队，而不是仅限于技术小组。这样的话，技术团队可大可小，比如说，我带过6个人的技术小组，现在带将近40人的研测团队，我的老大负责整个九游（现在逼格高了，叫做“阿里游戏”）的技术团队，人员规模是几百号人，大点公司的CTO，技术团队可能是上千上万人。
不同规模的团队，负责人的做法差别很大，以下回答部分是参考我的经历，部分是我自己推测的，如果大家在实际应用中应用这些技巧遇到问题，别打我哈 ：）
- 【5 ~ 10人团队】
这就是最小的技术团队，一般来说就是负责某个大业务系统里面的一个子业务，或者某个大平台下的子系统。
这个问题
1）负责人一定要技术强，业务熟悉，不求组内最强，但至少也要是前三的。
有的人看到这个说法后可能不以为然：“不是说要招聘最牛的人然后授权么”？
这句话本身没错，但用在这个团队规模就是错误的，原因是什么呢？
首先，大部分公司都有人力资源控制的，本来团队人员就不够，你还要区分一个做管理的，一个技术核心，浪费钱啊
其次，就算你招聘到了，这个规模的团队大部分事务都是具体的技术和业务细节，如果团队负责人只是负责转发邮件、组织会议、有问题就说“你们找XXX吧”、对外不参与业务讨论、也不参与方案讨论，嘿嘿，你当组内人员是傻瓜呀，你当核心人员是傻瓜呀，没有团队成员的信任，哪里来的领导力 ？
第三，就算大家表面上服你的领导（层级在那里，不得不服），但如果有一天核心走了怎么办？要知道招聘一个牛逼的人，可能半年1年都招不到，核心对你不爽，一走了之，你啥都不懂，其他人也一般，这个团队就陷入无序甚至瘫痪了。
有的朋友可能会说，那我招聘2个牛逼的人呀！听起来很美好，招聘过的人就知道这很难，面试了几十上百个，遇到想要的牛人就那么一两个，结果因为要价太高，公司还给不起 ：（
还有一个现实的问题，技术负责人自己技术不强，怎么能够找到牛逼的技术核心人员 ？
2）最重要的是培养下属
都提到了业务，团队，但以我的实际经验来看，当团队处于这个规模的时候，团队负责人对业务的控制力是比较弱的，更多的时候业务是由外部驱动的，比如说由产品人员主要负责业务规划方向，或者由大业务决定子业务，技术负责人最多建议，不太可能把控；
团队方面也是一样，技术负责人应该去争取团队利益，但能否争取得到，更多的时候看再上一层如何决策和平衡。
所以这个级别的技术负责人的主要职责是带领团队将安排的业务做好，并且手里并没有太多资源，这种情况下，组内人员能够从负责人那里得到什么利益呢？ 我觉得最主要的利益就是跟着负责人学到了东西，得到了成长。这其实又回到了我说的第一点，技术负责人自己要强，否则别人怎么从你这里学东西呢 ？
分享我之前的老大给我们传授的一个经验：30%做管理，70%做技术，按照这个标准来衡量自己或者你的leader，管理投入太多可能成了项目经理角色，管理投入太少可能整个团队就运转不畅。
- 【10 ~ 50人技术团队】
10 ~ 50人的技术团队，基本上就不是单个子系统或者子业务了，更多是一组相关业务，甚至就是一个完整的业务了，要知道大部分创业公司技术人员可能也就20 ~ 30人而已。
这个规模的团队的技术负责人，做法和10人以下团队负责人的做法就差异很大了，为什么呢？
主要原因是因为：整个团队分成多个小组。一般一个小组大约就是10人以内（贝索斯推崇的理想团队符合“2个披萨原理”，即一个团队吃两个披萨应该能够吃饱，否则团队就太大了）。
分成多个小组对技术负责人管理上的要求有和变化呢 ？
首先，你不可能关注每个人了。举个最简单的例子：季度沟通的时候，假设每个人30分钟，如果你每个人都沟通一下，50人的团队就要25小时，这意味着你基本上一周啥都不干就只能沟通了。
其次，你不可能参与每个系统的开发了。这个显而易见吧，50人的团队，各种系统少说7、8个，多的十几个都是正常的，你怎么可能去参与具体版本的开发呢 ？
第三，小组间的冲突协调现在需要你来处理了。比如说，A组说我们要这样做，B组说A组这样不行，那最后怎么办？ 就只能靠你来协调了。
第四，需要关注整体的情况。单个小组的质量和效率或者士气等情况对你来说已经不是最关键的，整个团队整体的情况才是你关注的重点。
第五，业务好多，你不可能每个都熟悉。每个小组负责1 ~2 个子业务，整体团队的子业务少则7/8个，多则10多个，你全部熟悉所有业务，这几乎是不可能的。
以上这些情况的变化，技术负责人的管理方式也需要采取不同的手段。
1）划分合理的组织结构
将团队分为多少个小组，每个小组负责什么业务，看起来无关痛痒，实际上是整个团队运作的关键。有一个著名的康威定律（不是电视机），大意就是：产品就是组织结构的体现。
具体如何划分，和公司的文化、传统、规范等相关，难以给出一个统一的标准。前面提到的贝索斯的2个披萨理论可以用于指导团队规模，我推荐团队规模符合著名的7+-2原则，即5 ~ 9个人，因为一个小组负责人关注的人数就是这个规模，太多了关注不过来，太少了团队做不了什么事情。
2）培养小组的技术负责人
包括技术培养、做事方式培养、管理能力培养等，具体怎么培养呢？ 你做小组技术负责人时怎么做的就怎么培养吧。
通过培养小组的技术负责人，然后由他们来管理和领导具体的每个人。
3）制定整体的流程和规范
整个团队的流程、规范（代码规范、发布规范、评审规范、测试规范、部署规范、灰度规范等）需要明确下来，各小组按照统一的规范和流程操作，尽量避免分歧和争议。通过规范和流程的约束，让整个团队运转更加顺畅。
4）把控团队技术发展和提升方向
这个时候技术负责人已经有一定的资源和权力，能够主导一些事情了，技术发展方向和提升方向就是最重要的需要技术负责人把控的。为何这个事情不能由小组技术负责人完成呢？一是因为小组的业务开发压力都是比较重的，没有太多时间来考虑和实施；二是因为小组技术负责人视野和信息毕竟有限，不一定能够识别出来。
举个我现在做的事情为例：整个系统的结构已经很不合理，但各个小组技术负责人都不知道该怎么做，如何协调资源，我接手后跟老大沟通，跟产品沟通，跟运营沟通，然后推动系统架构解耦的事情。
这个时候技术负责人能够掌握薪酬激励等资源么？ 看公司情况而定，我了解是大部分情况下还不会掌握这些资源，但是有一定的权力去在团队范围内分配资源。
- 【50 ~ 500 ~ 5000 ~ 50000技术团队】
这种情况我还没有经历，一般到了这个级别，都是总监、总裁、CTO级别了。我觉得之前的做法也都不适应了，我想了一下，这个级别的技术负责人，可能主要是负责如下几个事情了：
1）技术文化建立
文化看起来是个虚无缥缈的东西，但其实大部分人都能够明显的感觉到。例如：
你是要高薪招聘牛逼的人才，还是低薪招聘廉价人员？
你是要决定让技术人员完不成任务就加班，还是要决定我们要少加班，尽量做有价值的事情？
你是要鼓励大家技术提升，还是就当技术人员是苦力，女人当男人用，男人当牲口用 ？
当业务与技术冲突的时候，你是鼓励技术为业务让步，还是坚持技术底线 ？
你是准备培养开放自主的氛围，还是培养等级森严的制度？
。。。。。。。。。。。。。。。。。。。。。。
这些其实都是文化的一部分，而且为何到了这个时候技术负责人可以做这些事情了呢？ 简单来说就是技术负责人已经掌握了相关的资源和权力了。
2）公司技术平台的建立
当公司发展壮大后，业务肯定是越来越多，但这些业务所需要的很多技术都是通用的，例如：运维平台、数据库容灾系统、网络跨机房建设等，这些事情跨多个部门和业务线，除非级别够高，一般人都无法推动这样的事情落地。具体的案例可以参考阿里和腾讯的中间件或者平台系统。
怎么建？ 其实互联网技术发展到现在已经基本上形成比较固定的模式了，照猫画虎，依样画葫芦就差不多了，有兴趣的可以看看我的专栏：专栏：BAT解密：互联网技术发展之路
最后，细心的朋友可能看到我一直都没有提到技术负责人要精通业务这个点。这可能也是大家有争议的地方，有的人会认为技术负责人最后都要懂业务，甚至把握业务发展方向。以我的理解和经历来看，技术负责人在业务这部分的积累本来就少，术业有专攻，技术负责人的业务能力超越产品和运营，几乎是不太可能的事情，术业有专攻。当然，凡事都有例外，我之前的老大就是通才，而且每个都做的很好。但我相信大部分人资质和水平应该是达不到这样的程度的。
