编者按
本文的作者，是今年来增长迅猛的美国智能家居品牌Wyze的首席架构师刘天强。他曾是AWS Rekognition的创始成员，有丰富的技术团队管理经验。
质量和交付速度谁更重要？对开发者应该高压管理吗？定制度还是自动化？该招聘什么样的工程师？还有极容易被忽略的中层管理者困境：技术专业性和赢得领导层的长期信任，二者怎么兼容？
这些问题，相信本文能提供一个解决思路。以下是来自他的自述……
19年加入Wyze至今，从孤身一人到现在大约百来号人的团队，从搭班子到管理，中间遇到的大大小小的问题不少。一直也想找机会写下来，一来能把经验传播给团队，二来帮助自己将一些零散的想法系统化，三来造福更多想在技术创业领域大展拳脚的朋友。
速度vs质量
无论在创业公司还是大公司，这几乎是一个永恒的话题。对技术团队来说，永远面临着领导层和产品团队对于交付的压力，但同时也面临着草率发布以后未来被技术债反噬的问题。如何抉择或者平衡速度和质量，是所有技术团队管理者需要学习的重要一课，这里说一下我在做决策时的原则：在资源和时间允许的情况下，永远质量为王。
许多创业公司的朋友很可能不认同这一点，毕竟没有迭代和发布，就没有流量和收入，公司的现金会被迅速烧光。但这里有个前提条件，是“资源允许”的情况下。一般在B轮以前的创业公司，速度比质量更占优，因为大家关注点在于“生存”，但是B轮以后乃至上市公司，质量逐渐会比速度获得越来越多的关注，公司阶段越到后期，质量为王的效益就越发明显。
原因就在于四个字：边际效应。
一般来说，段数比较高的工程师在项目中思考更加周到、质量意识更高，当然反映在工资单上也更贵，但若公司收入增长曲率稳稳大于人员增长（例如收入指数增长，人员线性增长），越往后期，即便好工程师显著增加，收入和人员开销的距离也一定会逐渐拉大，如果此时在兼顾质量的同时速度跟不上，相比低质价廉手快但成长性偏弱的996团队，明智的管理层会选择横向扩张高质量的工程师来弥补战力不足，并且降低未来的安全和运维风险。反映在实际公司的经营中，早期工程团队的救火英雄往往是对内容了解，能够“Make it work”和“搞定问题”的执行者，不需要有强烈的质量意识和全局意识，但这部分人若在系统思考方面不成长，在后期质量为王的环境里就容易被业界经验更丰富、更擅长长线思考的同事们所取代，就造成了许多创业公司里早期员工跟不上后期发展的情况。
学会妥协，做双向方案： 现实情况下，资源无限的上下文几乎不存在，无论是创业公司有限的资金，还是大公司细到各个组的年度预算，都让技术团队的管理者无法永远在面对问题时无脑选择质量，这时候我们需要探讨的就是“妥协的艺术”，但敢于说“不”对于任何人都不容易。这里说一个我实际遇到的小例子：
在公司发布的一款智能硬件产品离预定的递交工厂生产的日期不到两周时，固件团队新来的负责人发现原来ODM设计的文件分区会让未来系统无法更新openssl等和安全相关的库。当时我们面临着来自产商、客户、以及公司回款的压力，如果在这最后两周重构底层固件，加上测试的时间，所有进度都会被打乱和推延，但如果不做这个更新，未来用户可能会因为无法升级固件相关的安全库，产生设备被攻击和数据泄露的风险。
两相权衡后，我选择说服业务团队顶住压力，将交付工期延后，最后公司也同意了我的决策。
这个决策现在看起来并不复杂，但包含着一个重要的原则：做双向方案。如果当日交付以后，我们能够较为容易地强制更新设备操作系统补上漏洞，我会选择先交付再修补，让业务和公司少扛压力。然而在当时的情况下这并不容易做到，因此我决定防范于未然。同样的决策原则，在有些时候我会偏向于“速度”，例如在上线前一些小比例的“边缘问题”没有妥善处理但很容易在后续迭代中修复。
风险管控
大原则只有一句话：承担可计算的风险。
可能不只是管理技术团队，生活其他方面这一条也同样适用。反映在技术团队遇到的问题中，常常和运维以及突发事故处理有关。
对于大公司来说，由于基础设施齐全，不太存在做决策前无法拿到足够数据的问题（虽然一些早期的组也可能有），但创业公司往往不是这样的，因此风险管控在实际操作中常常就落实到数据的可视化上。
我们公司曾经有一套早年外包出去的基础架构，下属几十个子服务和100多个API，文档不全，质量不高。但因为极其重要，内部成立了一个团队来消化和重构之，因为该系统信息繁琐，在开始的阶段十分难以下手。团队经常遇到的问题类似：是否应该要把这两个API合并？修改这段代码对系统整体的影响是什么？部署安全吗？
所有这些问题纠结的根本就在于：行动风险无法预估。但如果我们放任不做大刀阔斧的改变，只专注于做小修小补，一来团队会面临越来越多的公司内部压力和质疑，二来团队本身长期的运维压力也会逐步变大。
因此我们的决定是：与其乐观而莽撞地修改系统的功能，不如在对系统做任何实际性修改和重构以前，先给各部分加上服务级别的指标并按照统一标准给重要的服务加上工作台和警报，这样方便在测试环境中对所有修改预估风险并排出优先级，同时和过去的外包团队不尽其烦地请教不清晰的部分。
在这项工作的前几个月，该系统发生过几次因为历史遗留问题导致的事故，但因为并没有足够的指标和相关部分的了解，团队更多聚焦在减轻问题的方案而不纠结于根治，这在许多不了解情况的人看来是在“滑水”，但在团队辛勤劳作了4个月后，几次重要的部署彻底改变了过去该系统“一个月发生三次事故”的惨状，此后该系统运行极其稳定，最终也扭转了团队的口碑并且收获了信任。
宽vs严
没有人喜欢自己的老板做“显微镜管理”，但不得不说，事无巨细很多情况下确实能解决不少问题，尤其是技术岗的经理常常自己工程能力不输给下属。多管一些还是少管一些都各有各的道理，但仍然不乏原则。
总的原则是：管小团队适合从严，管大团队不能太严。小团队时期，领导自己需要下火线，对业务了解如果不驾驭在下属之上，很难服众，但是团队出现层级以后，如果层级高的领导事无巨细，反而是一种僭越，并且一定会让自己成为瓶颈。这里的问题在于，如果不事无巨细，如何保证团队的执行力？
19年的时候，公司还在极其早期时发生过数据泄露，大体是因为一个初级员工不慎将一些机器暴露在网络上引发黑客的攻击并且夸大。当时责任团队大致30人左右，事后反省时，我们几乎不关注员工的个人失误，而聚焦在管理的缺失上，核心问题在于：为什么团队经理无法在事故发生前就知道组员的操作失误并且及时制止？当时责任团队30多人，已经超过了经理能够事无巨细过问的范围，在帮助团队回顾具体事宜、强化必要安全措施的同时，我提出了两个比较显而易见的建议：
细分团队的层级：当时的团队，30多位工程师同时报告给1个经理，根本无法在小团队的层面从严管理，合理的做法是将团队划分成至多7人一组，由几位基层经理统驭，再汇报给高级经理。
这样一来可以保证基层的“严”，二来可以避免高层成为瓶颈。这个类似于Amazon的“Two Pizza Rule”。
强化自动化检测机制：中心思想是“在运维方面，人比机器更容易犯错误”，与其寄望于招到的永远都是明星工程师或者基层经理的事无巨细，不如尽可能把重复琐碎的工作交给自动化，降低管理成本，而且还能避免过多带着感情色彩的决策。
后来这两个建议都被团队采纳，执行了一年后再没有出现过重大安全事故，运维质量也有了质的提高。另外：从基层经理到高层经理的必经之路，是如何将“事无巨细”交给“制度和自动化”？这正是我们的下一个话题。
制度vs自动化
承接上篇的安全问题，如果需要在长期完全避免，则同时需要一套所有工程师都遵守的制度和一套完善的自动化检测机制。我们时常面临的问题是：哪些事情适合对团队订立制度，言传身教？哪些适合死磕自动化来替代人力？
原则是：能自动化的尽量自动化，资源所限无法短期内自动化的规则，主要靠制度和执行。原因是：对于确定性的任务，机器永远比人可靠。
近期的一个小例子：团队用到一个关系型数据库需要定期更换密码，但因为业务繁忙，工程师时常忘记。这种情况后续讨论的结果就是：通过自动运行的脚本来每月更换密码并且将其存入只有必要的工程师和服务能够访问的地方。这样一来经理不用每月都提醒下属更换密码，二来更方便管理密码的获得权限，两全其美。
上述这类自动化做多了以后，相关的团队发现需要手工干预的任务越来越少，制度的订立和执行成本大幅度下降，团队条条框框也少了，最终从经理到下属大家都开心。
自动化好处多多，但是因为工程资源有限，对于处理许多情况，很多时候团队不得不靠订立制度而非自动化。订立制度、撰写文档都不太困难，关键在于“执行力”。大部分情况下，制度的执行和管理者的强调力度成对数增长的关系，过分甚至偏激地强调制度的执行并不会显著地提高执行效率，有时反而事与愿违。因此，“执行力”的精髓在于“激励”而不非“强推”。
“激励”并不限于比较实际的和金钱挂钩的激励，很多时候可以是让员工意识到这么做利人利己、降低自己工作的好办法。就拿之前所说的自动化来说，如果要激励团队尽可能自动化，最有效的办法永远不是一味强调，而是让那些意识不强的员工强制执行一两次后，自己看到自动化对自己平衡生活与工作的好处。
信任的力量
这本著名的《团队的五个功能障碍》里面强调的最本质问题就是“信任”，具体到我们今天讨论的话题，就可以衍生出许多有意思的问题，其中想谈三个代表性问题：对于自己不熟悉的技术领域，是否完全放心放权？对于和非技术团队的合作，甚至是公司的领导和管理层，如果专业判断在某些情况下会影响到对方对自己的信任，是选择专业判断还是信任？如何获得信任？
对于自己不熟悉的技术领域，是否完全放心放权？
放权是扩张业务范围的必经之路，但新的领域往往面临着未知和风险，并且很可能不是你所擅长的，这时候学会如何寻找和管理代理人就异常重要。
领导自身对新领域的持续学习固然重要，但本文主要聚焦在管理上，因此关于“如何快速学习新领域的知识”这部分就略去不表。总的来说，我的原则简单概括为四字：严进宽出。具体展开来说：在选领域带头人时慎之又慎，但一旦选定，便无保留地信任对方的专业并给予充分的自由度。
原因也很简单：术业有专攻，尤其是技术领域，管理一个多元的技术团队不代表团队领导就一定了解每个细分领域的知识点和细节，但其通识、逻辑和思辨必须较大部分下属出色。这里举出我们之前创立固件团队的例子。
对于一家智能硬件公司来说，出色的端侧工程能力十分重要，但由于我们技术团队早期几乎所有核心人物都是云计算和AI背景，真正开始深度介入固件领域的时间非常晚。这当中有两个明显的难处：
- ODM投入较大，积累较多，作为人员资源严重不足的新团队，学习速度必然跟不上业务成长；
- 端侧技术栈偏底层，大量基于C/C++甚至是汇编和Linux kernel，市面上人才储备严重不足，主要原因是大部分互联网公司不需要和硬件固件打交道。
然而，作为一家长期技术栈必然大量依靠端云结合技术的特殊互联网公司，我们必须咬牙把固件这块硬骨头啃下来。于是，从2020年初开始，我们便踏上了寻人之路，先后花了一年时间，也只找到了个位数的初始成员，在经历了几番波折后，在年底方才找到了能够放心托付团队的负责人。虽然过程并非一帆风顺，但是对于“严进宽出”这条准则中的“严”有了更具体的看法：
对于技术团队的领导人来说，不在其领域的人常常无法精准地判断他的水平，但无论任何一个领域的带头人，其在计算机科学领域的基本素养必须扎实过关，逻辑思维能力必须强，这也成了“外行”评价“行家”的核心部分。
我上一家公司Orbeus在被Amazon收购以前，曾经经历过一轮严格的技术尽调，在持续3小时的展示和问答环节中，Amazon那边派出的PE虽然并非AI领域的专家，但我注意到对方在仔细倾听和消化我方的技术架构后，一边梳理知识点，一边以“假设我要学习这项技术”的态度做出提问，还问出了许多一开始我们自己都没想过的问题。在叹服之余，我也从中学习到了“通识”的重要性，这对我在Wyze组建多元化技术团队时如何鉴别人才提供了重要的启发。
业务扎实的好人才有其共性：通识强大、逻辑严谨、态度谦逊而且直面问题。
基于这些判断，我在面试阶段比较少问深度领域相关的问题，更多让面试者说自己的工作，然后抱着学习的态度做一些深入的了解，例如面试者常常会说自己做过的系统架构，那我就会问某两个模块间通信怎么加密的？证书怎么存放？如何在某个步骤发生问题的时候怎么容错？哪些指标可以用来评价特定模块的开发质量？另一种方式看起来更简单但你为什么这么做？这些问题非常宽泛，但是从回答中可以看出面试者思考问题的方式和面对挑战的态度。
业务层面过关自然很重要，但人才是否能够在团队中获得成功，尤其是高层人才，还需要至少考察两方面：动机和领导力。在固件团队最终找到合适的带头人以前，我们经历过一次波折。该团队第一任带头人业务十分扎实，在任一年业绩也可圈可点，却不到一年就提出离职，理由是希望出去“自己做点事情”。
这意味着我们选人时在对对方的动机和领导力的判断上出现重大问题，虽然每个人都有选择自己职业路线的自由和权力，但是选择团队重要合伙人的关键点在于“是否能够和公司一起成长”，无论是能力上还是财务回报上。如果无法以“共同成长”做为出发点，这个人必然会在某个时间节点下船，从而引出一系列突发事件。
再深入一些，虽然不是100%，但近两年我发现团队中的顶级成员和成长最快的新人普遍有一个共性：对自己所在领域和工作内容充满了热情并且舍得投入大量的精力，这种浓厚的求知欲在不自觉之间成为了他们和公司共同成长的基础，不仅为他们个人带来职业上的回报，也为公司带来巨大的价值。所以在判断一个人是否是个好的领域带头人时，这一点同样适用：强烈的求知欲和对自己所在领域的热情。
如果一个人谈到技术时没有办法容光焕发，而只是一味专注于自己将来职业发展或者待遇的话，那就趁早算了。
在经过千辛万苦找到可以拜托的人以后，下面就需要充分的信任，作为团队领导，也可以把注意力从业务转移到垂直领域的评价体系建立上，你需要和新来的带头人在最初的一两个月把第一年的范围和成功的标准制定讨论清楚，也可以让对方推荐一些领域相关的综述和文章，这有助于你能够提纲挈领地把握重点而不被带跑偏，尤其是一些学术性较强的领域，例如AI，很多时候一个细分领域的研究就可以帮助你从高层次了解大家努力的方向，进而获得决策能力，这类阅读不仅仅只限于开始的阶段，随着范围和优先级不断变化，你也需要读越来越多的综述来理解团队的整体认知。
Professionalism vs Trust？
大多数情况下，专业化会促进信任加深，但在少数且重要的环境下，却未必如此，典型的情况例如多个不同的团队合作时，一个团队的专业化准则和另一个团队发生冲突。智能硬件领域多的是这样的例子：技术想要高配高质，运营方面的成本考量不允许，产品方面上市时间考量不允许。还有一些公司过度注重财务模型，却忽略了长期技术和产品的潜在影响。
这里我的答案也很简单：Always Prioritize Trust over Professionalism。理由也不复杂：专业化的作用是把一件事做好，如果合作双方（N方）都没有了信任，事情都不用做了，又谈何“做好”？作为技术人员，我们的天性不像其他职业一样容易变通，尤其是资深工程师，对于技术方案吹毛求疵的程度有时就像从草堆里挑绣花针。如果一不合意就耽误业务，长久下来业务不是去找别的技术团队，就是把工程外包，最终结果是双输。
所以这里关键要把握一个度，有所为，有所不为，核心原则就是前文提到的做双向方案，只要不触及“不可逆”的底线，其他点都是可以拿到桌面上谈的，在大家把自己诉求开诚布公地沟通，做适当妥协的过程中，信任也建立起来了。
对于开发团队来说，需要特别提醒一点：产品团队对技术团队的方案建议，可以参考，但一定要思辨。这里所说的信任，具体来说是长期的，只要在不损害长期信任的前提下，一定要充分考虑专业性。归根到底，产品团队关注重点在于项目的交付，但技术团队的重点是怎么交付可以做得更好并且最小化将来的维护成本。一个极端但简单的例子：技术团队是否写UnitTest对于产品发布看起来影响不大，但是缺少了这一环，代码在许多边缘问题上的逻辑恐怕并不是工程师原来预想的那样，会大大降低代码质量，提高维护成本。在一些关键原则上，如果扮演“好好先生”，长远来讲，不仅不利于建立信任，反而可能会危害到早期因为“手快”建立起的短期信任。
如何赢得信任？
这个话题极其宽泛，但在本文的讨论范围内，行为准则大致离不开这几个关键词：坚持长期主义、行为和决策多数可被预测（看得透）、一诺千金、不轻易承诺、持续做事实证明正确的决定。
坚持长期主义：在“Professionalism vs Trust”这一节中提到了“长期信任”的概念，这是在任何情况下我们都需要争取的信任类型。如果一个行为能够在短期内赢得合作伙伴信任甚至增进关系，但长期来说却有害，那么一定需要抵制住诱惑。
表现在开发团队，最经常遇到的情况就是从产品经理处拿到一堆需求，对方问研发经理某月某日前能够完工么，研发经理一看时间觉得很紧，但为了迎合业务，在省掉UnitTest、加入一些quick & dirty的做法后，发现纯功能开发刚好能赶上进度就直接说ok。
工程团队少干活少动脑子，产品那边又能按期交付，大家都很开心，然后产品就这样发布了。可想而知，在用户不多的情况下产品问题也不大，毕竟没几个人会提反馈或者到SNS上写测评，但一旦量大到一个程度，每天公司的客服接到的都是质量问题的抱怨，工程师每天都忙着修琐碎的bug做不了新项目，士气低落，产品新功能无法推进，时不时还来一个整体宕机搞得全公司抓狂，最终越来越多工程师离职，在职工程师压力越来越大，新产品无法发布，发布了也无法取得用户信任，工程师和产品团队信任破产，全剧终。
本文作者：刘天强
原文链接：https://tianqiangliu.medium.com/
后续我们还会分享更多团队管理相关的文章，感兴趣的小伙伴可以关[LigaAI@oschina](https://my.oschina.net/u/5057806) ，也可浏览 LigaAI-新一代智能研发管理平台~
