18 技术管理者如何发掘写代码之外的能力？
你好，我是应紫门，目前在爱回收担任产研部门的负责人。今天我们来聊聊技术管理者如何发掘自己写代码之外的能力。
很多互联网公司的技术管理者需要兼具技术与管理能力，而这些技术管理者基本上都是从一线优秀的工程师中提拔上来的，我也是如此。在被提拔为技术团队的管理者之后的一段时间里，我一直有些焦虑，担心自己在日常管理上花太多时间，不能像之前做工程师一样写代码、学习新技术了，会逐渐丧失自己在技术上的优势。
这是很多新晋技术管理者跳出舒适圈后的第一反应。但实际上技术与管理并不冲突，成为管理者之后你接触的代码可能会比之前更多、更复杂。我们的重心应该在如何管理好团队上，因为成为管理者之后需要的就不仅仅是写代码的能力了，而是要发掘更多能力来做好管理工作。
抵制自己写代码的冲动
成为技术团队的管理者之后，首先要抑制的就是自己写代码的冲动。
当你的团队遇到项目上的问题，比如Deadline到期，很多新晋的技术管理者很可能会被诱惑到舒适区去解决项目当前的问题，相比于协调资源、激励团队等管理动作来说，卷起袖子直接上阵，熬夜加班写代码去完成相关的项目可能更有效。有些人甚至还引以为荣，觉得自己在关键时候对团队起到了帮助。
实则不然，这个时候恰恰是你学习有效管理的好机会，旧技能重复100遍只会增加熟练度，并不会让你的技术得到提升。时间是有限的，重复使用旧技能会大量占用你学习新技能的时间。而且这种“护短”行为，短期内看似解决了团队的危机，实际上是少了一次锻炼团队解决问题的机会，对团队成员的成长非常不利。克服这个问题是一个工程师成长为一个优秀管理者的关键。
如果我们在工作中遇到这类问题，应该如何正确处理呢？我们一起来分析下。
Deadline到期大多是因为前期没有把控好节奏，到了临近交付的时间点发现有问题可能已经晚了，这个时候我们可以重新和业务方Review需求范围，看能否在有限的时间内，能够达成一些基本要求的情况下，对需求做一些简化，同时需要基于目前团队碰到的问题重新设计技术方案并协调资源。事后也要及时复盘问题产生的原因和改善的措施，让团队获得经验，避免这种情况再次发生。
遇到这类问题，管理者要做的事情有很多，比如跨部门沟通、协调资源、改善流程机制等等，而冲到前面写代码是所有事情中优先级最低的。
其实之前如果你干得不错，并不用太担心一段时间没有写代码，特别是一线业务代码，技能会逐渐生疏。当你深入参与一些技术管理工作，比如技术方案评审、代码审核、事故复盘，并且在一些关键的技术决策上深入思考业务价值与实现成本之间的平衡，你会从一个更高的层面去思考技术的实现方式。经过一段时间的积累，再回到具体实践上，你会发现自己技术反而进步了。
写一些特定的代码
前面我们说了要抵制自己写代码的冲动，通常指的是业务代码，但并不是所有的代码都不能写。对于你团队要交付的项目来说，你不应该贡献“代码”，而是应该贡献你的“管理”并让项目成功。而对于一些不能直接带来项目产出但是技术管理者应该关注的领域，是可以写代码的。
- 提升效率的工具：开发这些工具是为了自动化一些管理流程，减少自己或团队的重复劳动。这类项目在技术的选型上比较自由，可以应用一些复杂和前沿的技术，你可以在这些项目中实践自己编码能力，而且这种项目还有个好处是对时间的要求不高，你不会迫于业务的时间压力动作变形。
- 最佳实践代码案例：管理者有机会看到更多人写的代码，通过大量Code Reveiw，可以总结出一些适合团队的最佳实践，写一些这方面的代码，建立代码规范，保证团队能力拉齐到一个统一的水位，帮助团队的项目质量整体提升。
- 为团队做一些基础架构相关的开发工作，这些开发工作非常通用，因为你可能比专门的基架团队更了解研发的需求，所以会比他们做出更有用的东西，比如业务数据因为合规需要在数据层面加密，那整个密钥的管理，数据的加解密方式你就可以整体设计，基于此你还可以做一个自动解密的应用整合到OA的审批里，这样需要解密数据的人可以自助走流程申请。
这些项目都是Manager可以涉足的开发领域，虽然它并不是一个具体的业务项目，但Manager确实可以通过这些项目来保持技术水平，并提升团队的效率。
除了写代码之外，其实技术管理者的工作重点有很多，比如如何参与产品设计、如何做技术规划，以及如何和领导汇报工作等等，与这些内容相比，写代码可能是其中优先级最低的一个。接下来我们就来看一下除了写代码之外，技术管理者的工作重点。
参与产品设计
深度参与产品设计是技术管理者拓展能力的良好途径。一个优秀的互联网产品，离不开产品经理、研发、交互设计师的共同努力。传统的认知里，技术是一个下游的角色，既无权决定解决方案，也不为业务的结果负责，只需要按照产品的要求做实现，把功能做完没有Bug就行，这样的产品不一定能成功，但长期来看技术团队一定没有成长。
从下游到上游
作为一个技术Manager，需要给产品团队带来一些改变，从一个下游承接需求的支持者转变为上游协作者，帮助产品和业务部门共同识别问题。
我在实际工作中就是这样做的，而且我也强烈建议你这样做。只有这样你才能更好地理解自己负责的核心系统。这个理解不光是技术实现架构层面，还需要延伸到产品层面，换句话说就是我这么做背后的目的是什么？解决了什么业务场景的问题？有了这层理解之后，你会和产品、运营有更好的交流，给他们提出更有建设性的意见，比如实现成本的最优解，因为产品和运营往往对实现成本没什么概念，而这正是技术人员的强项。
技术主导，勇于担责
除了日常给产品、业务提供有效建议外，有些适合技术主导的项目我们也应该勇于承担责任，并使用技术手段来解决。现在越来越多的案例证明，有些项目技术人员成为核心，能够释放惊人的潜力，特斯拉汽车就是一个案例，技术人拿到的不是要做什么，而是我们要解决的问题是什么。
另外在一些工具型的产品里，技术主导设计往往也会取得更好的效果，比如我们在做的一个手机质检工具，如何把一些非标准的检测项验准是项目的核心，这类问题需要技术先出方案，产品才知道应该怎么做，这个时候技术方案的可行性是前置条件，技术和产品配合才能做出一个好用的产品。
通过主动参与或主导产品设计，我们可以进一步了解技术的上下游，从业务的角度、产品的链路、技术调优等角度切入，开拓自己的视野，转变技术思路。
技术规划不要脱离业务
技术管理者在做技术规划时容易陷入一个解决技术问题的误区，在自己的OKR里面设了很多技术目标，比如服务性能的TP99要达到多少，Slow Query要降到多少，系统的可用性指标等等。这些都是非常重要且基础的指标，的确是技术管理者需要关注的。
但你会发现，这些目标今天可以写，明年也能写，一直用下去都没问题，但作为一个技术管理者你有没有考虑过这些技术指标和今年所在业务线的目标以及公司战略目标的关系呢？这些技术迭代带来的好处是什么，是否适合现阶段的产品架构，能否对公司的业务带来帮助？
比如一个业务还在验证阶段，技术设计上就按照DDD（领域驱动设计）思路对服务进行细致地划分，分别设计了N个微服务还考虑了很多未来的扩展性，然后经过一段时间业务没跑起来下线了，前期的这些技术投入都白白浪费掉了，如果对业务有一些深入的理解，这个阶段一个巨石应用才是最合适的选择。
对技术管理者来说，技术规划需要考虑业务的实际问题，需要往解决业务问题的方向做规划，我自己曾经也有一段时间认为公司业务变化比较快，组织架构频繁调整，因此对技术规划不是很重视，把重点放在了团队技术提升上，这其实是一种懒惰的表现，毕竟思考变化的价值是一件更具挑战的事情，不要让自己永远停留在业务的外围。
向上管理
除了上面我们说的参与产品设计、技术目标与业务目标相结合这些横向的能力拓展之外，我们还应该在纵向拓展自己的沟通能力。其中有一点就是很多人都不愿意提及的向上管理，但这其实是为团队和个人争取资源和机会的天然路径，所以我们应该正视并重视向上管理。其实我个人也不太喜欢那种所谓的预期管理或邀功式的向上汇报。我更愿意把向上管理理解为如何与你的Leader有效沟通。
不管你的Leader是技术线的管理者，还是业务线的管理者，沟通的目的都是为了相互认可，达成一致的目标。你需要先了解你的leader的阶段目标是什么，他/她在考虑的问题有哪些。这些事情不要去猜，要主动去了解，这些信息你可以通过开放的OKR或者1对1的交流获得。同时你也需要把你自己的目标和问题传达给leader，把和Leader的沟通当作研发项目管理来做，抓住几个关键节点：
- 项目立项阶段：在方向层面需要与leader达成一致。
- 技术设计阶段：把自己做事情的思路方案和leader交流一下，获取更高维度的建议。
- 研发测试阶段：如果事情有风险，需要及时暴露问题，不用害怕因为存在问题而受到批评。
- 项目上线阶段：这个阶段的沟通重点是对一件事情的最终价值的复盘，哪些做得好，哪些做得不好，未来如何改进等。
总结
好了，关于技术管理者如何发掘写代码之外的能力，我给出了4点建议，最后我们一起来回顾一下吧！
- 作为一个技术管理者，技术依然是你从业的基石，你可以通过写一些特定的代码来保持你的技术能力，但不要迫于交付压力直接为团队写业务代码。
- 带领技术团队参与产品设计，从需求支持者转变为协作者，提供有价值的技术思路，发挥更大的价值。
- 在做技术规划的时候，要与目前的业务目标相匹配，管理者需要了解业务线的目标和需求，然后做出合理的技术规划。
- 在项目的关键节点和领导保持有效的沟通，保证行动不跑偏。
最后我想说，技术管理者不应该拘泥于具体的技术框架，甚至也不应该只把目光聚焦在自己的研发团队上，横向上，技术目标如何与业务对齐、为业务助力，纵向上，如何进行有效地上下沟通，减少信息差，获取更多资源与支持，是技术管理者要考量的重点。
思考题
如果你团队面临一个技术问题，迟迟不能解决，来寻求你的帮助，你会如何处理？欢迎你在评论区留言和我讨论，也欢迎你把这节课分享给需要的朋友。
金句
- 石云升 👍（4） 💬（0）
如果你团队面临一个技术问题，迟迟不能解决，来寻求你的帮助，你会如何处理？带着团队成员一起讨论，从定义问题开始，在过程中尽量让团队成员自己解决，管理者只提供解决思路。走过一遍后，用文档记录整个过程。 我们经常说要做一个10X的工程师，这个很厉害。但我认为更厉害的是把团队打造成为一个10X的工程师团队。这个得依赖于每个成员解决问题的能力。
2022-12-17 - yanger2004 👍（0） 💬（0）
可以鼓励和团队内senior的开发一起讨论解决方案，不要自己一个人扑进去解决
2022-12-14