共计 4988 个字符，预计需要花费 13 分钟才能阅读完成。
你好，我是石东海。
前段时间我应邀跟一些企业做过一些交换，探讨在这个数字化时代，怎么去解决技术团队所面临的一些共性问题，包含技术思维转变和治理思维转变方面所经验的挑战。期间谈到了一些我集体的经验，以及这两年我从技术管理者转向业务管理者的一些成长实际。
不少敌人对我这一路走来的成长轨迹很感兴趣，心愿我能分享一下本人在成长过程中的心得。于是我也借着这个机会回顾了一下本人的成长历程，从新梳理了每一个成长节点，分享每个阶段我的思考，心愿这些思考能对现阶段的你有所启发或者帮忙。
我的经验并非那种互联网大牛的疾速成长门路
对于那些焦虑于“两年速成架构师，三年荣登首席架构师，五年成为 CTO”的同学，我的教训可能不太值得参考，命运给了我不错的回报，但并没有赐我一条捷径。细细回顾，十多年的技术工作经验中，我做了五年多一线技术开发，尽管期间也做一些兼带的技术治理，但并非真正意义上的技术经理，更像是一个 Feature Team Owner（FTO），并没有实质性的受权来赋予我管理权限。
但回过头来看，这段负责虚构团队负责人的经验对我前期的成长有极大的帮忙，因为这段经验，让我很早就意识到， 很多事件的推动和落地，不是靠职权影响力搞得定的，而是靠对事件的责任心，以及一贯绝对靠谱的口碑， 失去了大家的帮忙和反对能力落实上来，就是这个意识，让我有机会在一群人中怀才不遇。
逾越一：从优良的码王到 FTO
从优良的码王到 FTO，须要在事件上被动跨出边界，承当更大的责任。很多技术同学也会遇到这样的契机，下级让你承当我的项目负责人的工作，波及一些跨部门的单干和推动，不少同学因为感觉这个太费精力了，影响本人的技术倒退，不想纠结于一些内部协同和外部协调的琐事，还有一些同学感觉本人又没有失去正式的受权，哪有势力做这个事件呢，甚至有人感觉这是老板在 PUA 本人，给活不给权，给活不给利。
以我集体的教训，这其实是一个很好的成长的机会，横向协调和协同是工作的根本能力，即使是作为架构师，没有横向的合作能力和影响力，大概率是做不好架构师工作的。
我尝试过倒退一些技术能力比拟强的同学成为架构师，在推动一些架构演进和落地上，就是落不上来，很多时候须要我去补位，这外面最大的问题是什么呢？我认为还是因为架构师没有强影响力和合作教训。尽管技术能力自身没问题，然而影响力是须要本人去锻炼和打造的。下级管理者最多给你一把起始的推动力，修行还是靠本身。
我成为事业群技术负责人后，在抉择技术治理苗子的时候，大体也是这个思路，让一些看起来有潜在 Leadership 能力的同学去尝试做 FTO，的确有一些人很负责，起初逐步成为技术经理、技术总监，也有些同学将就地交付着我给予的工作，缓缓也就淡出了眼帘。起初我逐步意识到，Leadership 这个素质，是存在于认知层面的事件，很难去造就，更多靠筛选。
我发现一些技术总监甚至 CTO，常常忙于救火解决一线问题，很有可能也是犯了相似的谬误，把不太具备 Leadership 认知（但可能技术水平真的不错）的人扶到了管理者的岗位，以至于本人被迫不停地向下补位。
其实业务管理何尝不是这样。我最近在跟同学们交换的时候提到一点，咱们常常谈责权利，在传统企业，责权利可能是同步到位。然而在大多数互联网企业，个别都是先给责，通过测验后给权，最初给利，比方降职涨薪等等，须要一些提早满足感。可这种模式，往往被不少同学认为是在被 PUA。我集体的职业倒退经验了很多这样的过程，我很感谢我的领导们在看到我的后劲时，大胆地给了我锤炼的机会，否则哪有明天的我， 我成长的每一步都在逾越我的职权边界，去承当更多责任。
逾越二：从 FTO 到技术经理
从 FTO 降职到技术经理之后，除了对事负责，更要重视人和团队，做到人与事联合，用人成事，借事育人。从集体贡献者变质到管理者是一件十分艰巨的事件，也是很多技术管理者的成长路线中十分重要的一环，FTO 更多是对事件负责，而技术经理除了对事件负责，也要对人负责。
我已经和不少一线管理者有同样的想法，老板信赖我，让我带团队，那我就把团队的事件做好，让老板释怀就好了，直到有一天我被老板问到团队同学的倒退和成长状况，这是我压根儿没认真思考的事件，老板苦口婆心跟我说了那句我这辈子都不会遗记的话：“你是这个团队的负责人，你有责任和任务帮忙大家成长，让大家变得更好”。
而我一路上也有幸失去领导给我的机会和领导，因而我很违心“代代相传”，以至于我每到一个组织，都会重点拎出“成长”这两个字，让它成为咱们组织很重要的一个文化。我在公司同学们中的口碑不错，倒并不是因为我给大家带来了多少物质利益或者降职机会，而是我发自内心地违心帮大家答疑解惑，凡是能给同学们成长助上一臂之力的中央，我根本从不悭吝。
在这个过程，我也的确经验过被质疑，甚至干过小白兔拿胡萝卜钓鱼的事件，给那些并不在意成长的同学大谈如何成长。我搞过很多流动，技术分享会一搞就是保持四年，八九十期，请了公司内外部很多人来分享，我也搞过代码大赛，让同学们一比“武艺”高下，来造就工程师的文化，我还组织过很屡次读书会，我全力支持外部的技术创新和技术开源，我甚至强行推过两年多的每周小作文，让技术同学总结当周的技术和业务思考，也曾因而被一些同学骂上匿名区。
回头看来，尽管有很多对我的不满，然而我已经的冤屈都早已云消雾散。起初始终感觉，初心向善，不惧谰言，哪怕我的所作所为只对其中一个人有用，我感觉也是值得的，我不也是有幸在前辈们的帮忙和领导下走过去的其中那一位吗？
逾越三：从技术经理到技术总监 /CTO
再往后就是从技术经理降职到技术总监 /CTO 了，这是一个更大的逾越，Manger of Manger 最大的挑战有两个，一个是人的层面，另一个是业务的层面。
人的层面
人的层面是因为团队的扩充，开始逐步焦虑本人的“掌控力”，这种掌控力不是说势力诉求，而是对人员治理的确定性。在小团队的时候，每个人在做什么都是清清楚楚，整个组织的后果也往往在预期之内。团队到肯定规模后，精力有限，很难把握每一个细节了。这个时候面临的抉择是，我是不是须要设计更多层级。如果是，我怎么去抉择和倒退我下一级的 Manager。
很多技术管理者崇尚硅谷文化，抉择扁平式治理，同时几十个人甚至上百集体间接向本人汇报，这齐全是误会了扁平式治理的外延， 扁平式实质是信息传递和决策的扁平 ，当咱们集体精力有限，而且团队自驱力不够的状况下，这么多的直属上司，基本上很难治理过去，本人累得半死不说，上司也很焦虑，不分明老板到底要什么。适度的层级是十分必要的。接下来怎么去倒退，并用好直属 Manager，也是个“很技术而且很艺术”的事件。
我的确也在这方面经验过挫折，2016 年我过后团队一百多人，团队里有一个挺不错的管理者，技术能力强，业务能力也强，组织治理能力也不错。那个时候我像很多高阶技术管理者一样，很喜爱深刻到细节，替代性地为团队做了很多决策，并沾沾自喜。在这个过程中当然会呈现我的想法和我的上司管理者想法之间的差异，恰好这轻微的差异我没有留神到，直到有一天，这个同学向我提了到职，我怅然若失，我心想我对你这么好了，你还要怎么样。
起初才理解到，一线同学因为咱们轻微的思路差异，摇晃到手足无措，我才意识到问题有多重大。起初的日子里我特地留神这些方面的细节，当然我也不可能什么都不论，缓缓到起初造成了方法论，一个是隔级理解状况，逐级布置任务，另一个是 Manager of Manager 最重要的是向下赋能，向上补位。前面我倒退了很多技术总监，咱们都成了极好的敌人。
后面咱们提到从技术经理逾越到技术总监 /CTO，面临两大挑战，一个是咱们刚刚说的管人方面的挑战，另一个就是业务层面的挑战。
业务层面
业务能力是高阶技术管理者必须具备的基本素质，然而很多中高阶技术管理者比拟自满，总感觉业务同学没有零碎思考的能力，感觉业务总是想不分明，甚至感觉如果本人来操盘，业务应该怎么怎么好，大有“我本将心向明月，奈何明月照沟渠”的无奈感。我听到过十分多这样的声音，其实已经我也是如此，直到我本人对业务指标负责的时候，我才真正了解了“敬畏”这两个字。
2017 年的时候，我是滴滴品质出行事业群的技术负责人，我那时候对专车业务的智能化经营特地感兴趣，心愿构建一套智能的城市化经营零碎。过后专车的用户经营负责人 R 老师也很反对我，咱们平时有很多对于业务的交换。R 老师是十分优良的用户经营专家，听了我的诉求，划了四个城市给我经营，由咱们技术来对立出用户经营策略。我特地兴奋，大有撸起袖子加油干的精力，直到折腾了一个多月后，R 老师问我啥感觉，我说我想杀了产品和技术来祭天。
技术的逻辑推理实质上都是假如，你感觉依据推论要产生的事件，往往没有产生，零碎也好，算法也好，不在业务中迭代，不能真正解决场景问题，就只是个辅助工具。而业务负责人是要对这个业务最终后果负责的，这个世界很多事不是输出就有确定的输入，很多波及经营的事件，很难用繁多维度的对错去掂量，波及太多短期和长期，主指标和参考指标之间的衡量和取舍，所有的取舍背地，都是责任和压力。
因而我集体的感触是，作为技术总监 /CTO，在学习业务上， 应始于谦卑，成长于独特承担责任，有机会要真正深刻到业务中，尝试去承当业务指标 ，能力更好地答复“技术为业务发明什么价值”这个问题。
最近跟很多企业的 CEO 聊天，有一些独特的反馈是，本人的 CTO 专一技术研发，尽管也很怠惰，然而技术和业务脱节很厉害，相互鄙视。为此这些 CEO 在其中不停协调。我通常会毫不避讳地倡议，你能够思考换个真正的 CTO，如果技术负责人没有前置的业务思考能力，只能在后端做交付和自以为是地开展业务场景技术建设，怎么能胜任技术负责人的角色呢？
尽管我本人是技术出身，但我自认为比拟胜利的事件是起初负责专车供应侧效率的指标，真正落实到了一线，从产品技术到区域落地，全面拉通解决问题，那真是从上到下地理解和学习。技术和经营，虽说分工上有差别，可职责上哪分你我，也正是那段时间的锤炼，我真正博得了业务的认可，后续走到事业部总经理的岗位。
正如后面所说， 我始终举着手，挑战着我岗位职责范畴以外的事件 ，就像篮球场上只有永远举着手，总有一天篮球会落到你手上。
逾越四：从技术管理者转向业务一号位
从技术管理者转向业务一号位，这是一个很大的课题，期间所遇所思所折腾的，足够后续再写一篇长文了，这是另一个维度的思维转变。
2019 年底，当我接下事业部总经理岗位的时候，我才意识到，负责业务的其中一个模块，几个指标，和负责整个业务有着根本性的不同。我既是业务倒退的首要责任人，也是业务危险兜底的首要责任人。有一首印尼歌曲叫做蜂蜜和毒药，就是那个样子，左手是蜂蜜，右手是毒药，须要时时刻刻在左右手做判断。
再回头看做技术的日子，那些压力和挑战，相对来说还是比拟云淡风轻的。我已经也是十分鄙视业务侧疯狂迭代批改需要，我甚至讥笑他们以“拥抱变动”的借口来拆穿本人思考上的欠缺，我也曾和很多技术管理者一样，指责业务管理者用战术上的怠惰覆盖策略上的懈怠，直到本人直面不确定的市场环境，才晓得咱们可能被迫须要做非常筹备来应答一分的可能性，当这一分的可能性也灰飞烟灭后还要激励本人和团队，咱们还有很多机会。
我真的特地想跟技术管理者们说，好好珍惜你们还在为战术勤奋努力的业务管理者，至多他还在给大家带来心愿。这几年，我再回味我当初给技术团队设立的三步走，很是快慰，没有辜负和我单干的那些总经理们。从做好高质量高效率交付，撑持业务倒退，到深刻业务，通过产品技术晋升业务测验效率，再到通过数据和算法洞察业务危险和机会，驱动业务翻新和倒退。幸好，有所小成，也不辜负那些跟我一起战斗至今的技术和产品兄弟们，至多咱们都在成长。
小结
最近特地喜爱一首诗，苏轼的《观潮》，“庐山烟雨浙江潮，未至千般恨不消，到得还来别无事，庐山烟雨浙江潮”。
咱们很多技术同学都在谋求本人毕生的 Spark Time，比方首席架构师，比方 CTO，当咱们有一天最终失去的时候，如同并无什么不同。技术的意义和价值重在平时一点一滴的奉献，踏踏实实做好身边每一件事，砍柴即砍柴，担水即担水，写代码就认认真真写，带团队就用心带，人生也是如此，每一件事只有用心了，都是功不唐捐。
以上，与渴望成长和成就的你共勉。
文章起源：极客工夫《技术领导力实战笔记 2022》
