从技术专家到总经理，在不确定中探索和成长

你好，我是石东海。

前段时间我应邀跟一些企业做过一些交流，探讨在这个数字化时代，怎么去解决技术团队所面临的一些共性问题，包括技术思维转变和管理思维转变方面所经历的挑战。期间谈到了一些我个人的经历，以及这两年我从技术管理者转向业务管理者的一些成长实践。

不少朋友对我这一路走来的成长轨迹很感兴趣，希望我能分享一下自己在成长过程中的心得。于是我也借着这个机会回顾了一下自己的成长历程，重新梳理了每一个成长节点，分享每个阶段我的思考，希望这些思考能对现阶段的你有所启发或者帮助。

我的经历并非那种互联网大牛的快速成长路径

对于那些焦虑于“两年速成架构师，三年荣登首席架构师，五年成为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》