技术管理者的困惑——技术与管理应该如何平衡？

原创不易，求分享、求一键三连

前段时间有个粉丝与我讨论了一个问题：

小钗，我半年前从技术经理升职到了技术总监，但这段时间的工作很恼火：一大半时间要去开各种产品会，还有一些时间要去处理团队扯皮，这导致我写代码的时间越来越少，半年下来感觉技术毫无成长，接下来该怎么办呢？

该同学的问题十分常见，而这里真正的问题是：程序员转型管理后，如何平衡技术及管理的精力投入。

然后看最后一句“技术毫无成长，接下来该怎么办”，这里是第二个问题：为什么技术Leader不写代码会感到焦虑？

这里围绕这两个问题开始展开。

技术大神的路线

“学而优则仕”这句话在技术界也行得通，技术好的人会被尊称为大神或者大佬，他会受到技术人员天然的尊敬，这种大神光环所带来的势能对他后续工作开展有莫大的帮助，即：

1. 技术好可以获得莫大的个人成就感；
2. 技术好可以获得极大的势能，对实际工作有莫大的帮助；

综上，技术好对个人来说是双倍快乐！所以大家会对他沉迷不以，一旦没有成长当然会陷入焦虑。但技术好的背后有两个重要问题：

• 时间成本

优秀程序员谁都喜欢，但技术好这个事情从来都不是那么简单，他需要耐得住寂寞。

因为单就基础知识如操作系统、数据库、算法，一套连招下来很多人三年都搞不明白；到后面工作中的各种疑难杂症，如性能问题、并发问题、复杂架构的维护问题，精通其中任何一个领域，都需要投入长年累月的时间，有些领域光是时间投入还不够，还必须有对应场景，所以成为一个技术好的程序员其实很不容易！

但是技术好并不意味着工作好或者产出好，因为长年累月的跟代码打交道，在与人交流方面会有一些小毛病，甚至一些程序员会被认为是一朵奇葩；

另一方面因为大量时间投入到了技术研究，对业务的理解会打折扣，甚至一些技术人并不想要关注业务实现，这些都极大的制约了其真实的产出能力。

• 专业壁垒

除了大量时间成本外，技术本身也是分领域的，除了少数大神，程序员都是在某一块专精，比如后端、前端、iOS、Android...

精通后端后能不能也精通前端？当然可以，但再学一个端口的边际收益太低，比如后端架构师待遇已经很高了，再多获取一个前端架构师的title收益不大，多数程序员并不想做这个事情。

另一方面时间是有限的，你写后端代码的同时没有办法写前端代码，所以多数技术人员只会选择一个领域重点发展，除非那个领域不行了，不得不转方向。

这也是很多技术Leader面临的问题，技术体系旁枝错节，很难全部精通，这就是所谓的专业壁垒，因为收益太低，一般人不会选择去突破。

• 发展选择

如上所述，成为技术大神的代价是大量的时间投入，长时间的面对代码也会导致思维方式的改变，最终的结果就是对真实世界的认知不够全面。

另一方面，技术领域本身又会细分，多数人只能精通其中一块，要想职业生涯更进一步当然就会有取舍，技术专家与技术Leader两个路线选择就出现了：

1. 程序员到某个阶段一些会采取纵向深耕，比如Android方向同学，可以在音视频领域深耕，这种做得深了会成为领域专家待遇很高，但问题是可能以后的路很窄；
2. 另一方面一些同学会采用横向的方式扩展自己的价值，比如转技术管理，或者变成业务专家，这个选择的问题就是技术很难再进一步了；

凡事有利有弊嘛，成年人的世界总是存在取舍，但两种选择都是常见的出路。

真假Leader

从赛道来说，是这样的：

1. 程序员->技术组长->技术专家->领域技术专家；
2. 程序员->技术组长->技术经理->技术总监->CTO；

技术经理是个很大的分叉口，到这里多半知道自己适合什么，一些技术经理在工作一段时间后发现自己不能适应，便会回归技术路线，到技术总监后再转技术专家的还是比较少。

回到粉丝案例：刚从技术经理进阶到技术总监，所以他事实上还是技术经理思维，在这个阵痛期没有感受到总监带来的好处，更多的是发现自己的核心技术竞争力在丢失，所以感到是否焦虑。这里就引发了一个问题：

技术经理和技术总监有什么区别？

技术经理也是我们常说的一线Leader，是第一个真正具有汇报关系的Leader，一般规模在十人左右，这种小组有个特点：技术经理就算技术不是最好，但总体还是能服众的。

对于程序员来说，技术好坏直接关乎待遇，所以大家都愿意跟着技术好的Leader学习，技术不好在团队里是站不住脚的，技术强弱直接关乎话语权之争，也是因为如此，技术经理会很注重自身的实力成长。

技术经理的工作比较简单，多是带领小团队处理具体项目，可以是技术项目也可以是业务项目，经理和一线的关系更像是带着他们一起干活。

我们一般不认为技术经理是真正的Leader，因为他们是不具有资源分配权限的。

总监之于经理表面的不同是管理规模变大了，根本的不同是总监开始掌握了团队资源分配权限，并且需要处理的问题更加复杂了，所以技术经理与技术总监主要区别有两点：

1. 总监开始涉及资源分配问题；
2. 总监需要处理的场景更加复杂；

这里再次回到Leader的能力模型和Leader的五件事：

此图可以更好的说明区别：

1. 总监需要做团队接下来的目标设计；经理更多关注下派任务；
2. 总监需要做团队梯队建设；经理更多关注自身能力提升；
3. 总监需要向上管理拿资源、分配资源；经理更多关注具体任务资源够不够；
4. 总监需要开始尝试使用机制流程解决全局问题；经理更多关注具体问题的处理；

从Leader的五件事的设计上，就没有要求总监一定要写太多代码，而是要有全局视野，并开始思考降本增效的问题了。

所以，技术经理职位更多的是一个缓冲带，程序员可以在这个时间窗口找到自己到底适合做什么。

至此，就可以聊聊“技术管理双线并修”问题了。

如前所述：技术是存在专业壁垒的，你是因为某个技术领域做的出色才被提拔成了总监级Leader，而已经选择了总监管理路线，自然就不能走领域专家路线，那么这个场景下你是要并修什么？

• 后端出身的技术总监，非要去教前端Leader做事，这不合适吧？
• 前端出身的技术总监，几年没写代码了，非要去跟前端Leader讨论Backbone多么优雅，这有必要吗？

这里想要表达的是什么呢？这里想要表达的是大家不要总想去做简单的事，不要在熟悉的领域逼逼赖赖，那很遭人烦，因为那是降维使用，这个是一个常见现象：很多大Leader看见一线的工作就眼红：

可以在几个小项目上打出超预期的战斗，或者扶大厦于将倾，在某个“烂尾”项目做兜底，这样很容易引起大家的注意。

但将简单的事情做得超出预期，似乎并不是我们应该做的，巴西打国足一个5:0也并不值得骄傲；湘北打败王者山王后被爱和秒杀，只能说残血被收割了，并不能说爱和多么牛逼。况且，简单的事本是别人的经验包...

有些leader定位不清晰喜欢抢下面同学活干，这种行为能带来「巨大的安全感」，这种安全感甚至是「可触摸的」：

技术总监过于专注技术细节，多半是在寻找安全感，缓解焦虑...

总监的“技术提升”

既然选择总监这条路，那么就要做这条路上的“技术突破”，可以使用以终为始的方法，看看技术负责人的能力要求是什么，就我现在的认知，要求有二：

• 成本中心

技术负责人最重要的工作是让其他CXO理解、认可并且支持技术部的工作，否则作为成本部门，在公司的地位会很低。

• 技术创新

光是让其他部门理解还不行，技术还需要创造价值，所以需要做技术创新。

上面的两个描述不够具体，走技术总监路线的同学需要不停的反问自己一个送命题：

技术部对于公司的价值是什么，与外包团队有何不同；

如果一时间没有太好的答案，那么以下问题需要先进行解答：

1. 迭代速度真的不能再快了？
2. 工程、技术重构类项目的价值阐述？
3. 如何降本增效？
4. 如何在高管会上说人话，如何让其他部门不会认为我们是工具人？
5. 在高管会上，除了这个BUG我下去处理以及资源问题我去想办法外，还有什么可以聊的？
6. 可不可以在不写需求的情况下完成项目？
7. 技术团队的产出如何量化？
8. 技术部的话语权如何提升？

拜托了各位，真的想要技术提升，请解答以上问题，不要老是盯着几个技术问题秀操作，来咬点硬的！

技术是个成本部门，并没有自己的产品，也不带流水！因此，技术部门虽然不可或缺，却未必非常重要，这也是很多技术总监会面临的一个问题：

多数时间去写代码了，却对代码要解决什么领域的问题不够敏感，很容易沦为工具人。

而高管会议时，你说的性能优化、模块重用、效率提升天老爷才感兴趣呢？甚至个别同事连研发和IT都分不清，这还如何玩耍？

做什么创新？

技术的价值在于场景应用，但创新的底色是足够的信息输入，如果技术总监对业务思考较少，对业务场景化创新完全没想法，这就很难了！

走出代码世界，更多的参与真实世界，多见一见业务的发展和困难，是技术第一梯队最需要做的事情。

一切能够被代码化和算法实现的，我们都应该去关注，任何能被技术解决的问题都应该优先考虑技术，这里具体的一些场景可以是：

1）我们能不能根据技术手段比如爬虫，拿到用户的数据，给不同的用户打不同的标签，对几百万用户做一个分层管理，有了这个分层和标签系统后，产品端再针对不同类型的用户提供不同的定制服务，标签、分类做得好，才可能做出精准的千人千面服务；

2）一些数据打通成本很高，技术上能不能协助打通，比如公安系统与业务系统（酒店系统、银行系统），我们能通过人脸识别，精准的知道这个用户到底是谁，在哪从事什么工作，再做进一步产品设计；

3）AI化可以替代哪些人工的工作，可以替代这些人工工作到什么地步，是部分替代增加效率，还是完全替代降低成本，当前每次交易成功都有百分之多少的人工成本，技术能将这个成本降低到什么程度？

4）...

以上的任务都要求对业务足够的了解，并且具备独立思考能力。

对于技术部如果所有的需求都是来源于外部团队，接到需求就做，如果出错了，再不停打补丁，没有自己的思考，不能提前6个月甚至12个月布局业务所需的技术，这种后置的成本很高。

对于业务，技术这块到底有什么核心优势？这个需要好好的面对。

不能总是去做很多短线操作，比如：做一些技术重构，在稳定性上发发力，然后再招一点人在做下工程建设，搞搞Devops嘛，最后质效数据是好看了，想来好像确实是解决了一些焦虑。但做加法，不面对自己，出来混，终究要还的。

选择总监路线就要思考技术核心竞争力到底是什么，在公司的分工和定位到底是什么，不要去找一些短线操作，以为能够有捷径，这个没有意思，而且长期的看，也确实不会给公司留下什么有价值的东西。

慢慢的回归到日常工作、业务日常，去做那些最艰难但最有意义的事情。无非就是从一个技术，转型成一个技术产品或者业务技术。每天去跟产品开一次产品会，去帮他们调调需求，就静下心来去好好做。

真的做了这步，发现路还挺长的，要转型其实还挺多的。

面对困难，就如张艺谋所说”接受是我最大的哲学，先接受，再谈创新改变“

业务架构师就是这个场景下的产物，即⼀个优秀的技术站在业务⻆度思考问题，扮演部分产品、运营⻆⾊，站在⼯程效率⻆度与产品业务⽅⼀起解决实际问题。

说白了就是——结合业务做技术创新...

业务是信息输入是底色，技术是创新能力，底色+能力=创新的可能

其实从个人发展来说，也不外如是：

1）更大的认知

比如，之前管50人团队，现在能管500人团队。

2）更多的认知

比如，之前做了两年开发，又去做了两年产品，再去做了两年语文老师。

3）1+1>2的认知

比如，两个相关联的领域，先做了两年技术，然后做了两年产品，最后成为一条业务线负责人。

这里比较晦涩，举个不恰当的例子是，学了九阳神功，又学了九阴真经，最后达到了1+1>2的效果，Hybrid就是这类产物。

业务工程师便是要融合业务与技术两个领域，设计出更好的结果，这里的输入是业务及技术知识，产出可以是产品、服务、合作流程、合作机制等。

最后总结一下：既然选择了技术总监的路线，那就要放弃纯粹的代码技术，拥抱更复杂的业务技术，创造更多的价值。

好了，今天的分享就到这，喜欢的同学可以四连支持：

想要更多交流可以加微信群：