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