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

今天是《技术领导力实战笔记》的最后一篇，我准备分享石东海老师关于技术人员成长为总经理的心得与体会。以下是东海老师的自述。

我的经历并非那种互联网大牛的快速成长路径，我从业十多年的技术工作经历中，有五年多的一线技术研发，虽然期间也兼带一些技术管理，但并不是真正意义上的技术经理，更像是一个 Feature Team Owner(FTO)，并没有实质性的授权来赋予我管理的权限。

但回过头看，这段担任虚拟团队负责人的经历对我后期的成长有极大的帮助，让我更早意识到很多事情的推动和落地，不是靠职权影响力搞得定的，而是靠对事情的责任心，以及一贯相对靠谱的口碑，得到了大家的帮助和支持才能落实下去，就是这个意识，让我有机会在一群人里脱颖而出。

跨越一：从优秀的码王到 FTO

从优秀的码王到 FTO，需要在事情上主动跨出边界，承担更大的责任。很多技术同学也会遇到这样的契机，上级让你承担项目负责人的工作，涉及一些跨部门合作和推动，不少同事觉得这个太费精力，影响到自己的技术发展，不想纠结于一些外部的协同和内部协调的琐事，还有一些同学觉得自己又没有得到正式的授权，没有能力做这个事情。还有人会觉得老板这是在 PUA 自己，给活不给权，给活不给利。

以我个人的经验来说，这其实是一个非常好的成长的机会，横向协调和协同是工作的基本能力，即便作为架构师，没有横向的协作能力和影响力，大概率是做不好架构师工作的。

在我成为事业群技术负责人之后，在选择技术管理苗子的时候，我会选择那些有潜在 Leadership 能力的同学去尝试做 FTO，确实有一些人很负责，后来逐渐成为技术经理、技术总监，也有些同学将就地交付着我给予的工作，慢慢也就淡出了视线。后来我做逐渐意识到，Leadership 这个素质，是存在于认知层面的事情，很难去培养，更多只能靠筛选。

有些技术总监甚至 CTO 常犯一个错误：把那些不具备 Leadership 的人扶到了管理者的岗位，以至于自己被迫不停的向下补位。

跨越二：从 FTO 到技术经理

从 FTO 晋升到技术经理之后，除了对事负责，更要注重人和团队，做到人与事的结合，用人成事，借事育人。从个人贡献者蜕变为管理者是一件非常难的事情，也是很多技术管理者成长道路中非常重要的一环。FTO 更多是对事情负责，而技术经理除了对事情负责，也要对人负责。

怎么负责呢？管理者有责任和义务帮助大家成长，让大家变得更好。关键词：成长，变得更好！

跨越三：从技术经理到技术总监/CTO

从技术经理晋升到技术总监/CTO 是一个更大的跨越，这里最大的挑战有两个，一个是人的层面，另一个是业务的层面。

人的层面

人的层面是因为团队规模扩大，管理者开始焦虑自己的“掌控力”，这种掌控力不是说权利诉求，而是对人员管理的确定性。在小团队的时候，每个人在做什么都是清清楚楚，整个组织的结果也往往是在预期之内。团队到一定规模后，精力有限，很难把控每一个细节。这个时候面临的选择就是，我是不是需要设计更多层级？如果是，我怎么去选择和发展我下一级的 Manager？

很多技术管理者崇尚硅谷文化，选择扁平化管理，同时几十个人甚至几百个人直接向自己汇报，这完全是误解了扁平式管理的内涵，扁平式管理的本质是信息传递何恩决策的扁平，当我们个人的精力有限，而且团队自驱力不够的情况下，这么多的直属下属，基本上很难管理过来，自己累的半死不活不说，下属也很焦虑，不清楚老板到底想要什么？所以，适度的层级是非常有必要的。

业务层面

业务能力是高阶技术管理者必备的基本素质。很多中高阶技术管理者比较自满，总是觉得业务同学没有系统思考的能力，觉得业务总是想不清楚，甚至觉得如果自己来操盘，业务应该会怎么这么好。我听到过很多类似的声音，甚至我自己曾经也这样想过。直到我自己对业务指标负责的时候，我才真正理解“敬畏”这两个字。

技术的逻辑推理本质上都是假设，你觉得根据推论要发生的事情，往往没有发生，系统也好，算法也好，不在业务中迭代，不能真正解决场景问题，就只是个辅助工具。而业务负责人是要对这个业务最终结果负责的，这个世界很多事不是输入就有确定的输出，很多涉及运营的事情，很难用单一维度的对错去衡量，涉及太多短期和长期，主指标和参考指标之间的权衡和取舍，所有的取舍背后，都是责任和压力。

我个人的感受是，作为技术总监/CTO，在学习业务上，要始于谦卑，成长于共同承担责任，有机会要真正深入到业务中，尝试去承担业务指标，才能更好的回答“技术巍峨业务创造什么价值”这个问题。

跨越四：从技术管理者转向业务一号位

从技术管理者转向业务一号位，这是一个很大的课题，期间所遇所思所折腾的，足够后续再写一篇长文了，这是另一个维度的思维转变。

最后，我把这篇文章里我最喜欢的一句话分享给大家。

我们很多技术同学都在追求自己一生的 Spark Time，比如首席架构师，比如 CTO，当我们有一天最终得到的时候，好像并无什么不同。技术的意义和价值重在平时一点一滴的贡献，踏踏实实做好身边每一件事，砍柴即砍柴，担水即担水，写代码就认认真真写，带团队就用心带，人生也是如此，每一件事只要用心了，都是功不唐捐。

我的心得

从我自己的晋升经历来看，懂业务业务无疑是非常重要的一个原因。因为懂业务，所以可以给员工做培训。因为给员工做培训，又促成了我给团队做分享。因为做分享，我开始参与跨部门之间的协同和项目的管理。因为这些，才有后来的团队管理以及在公司外接触到各种各样的人。

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

课程链接：