原创不易,求分享、求一键三连
前段时间有个粉丝与我讨论了一个问题:
小钗,我半年前从技术经理升职到了技术总监,但这段时间的工作很恼火:一大半时间要去开各种产品会,还有一些时间要去处理团队扯皮,这导致我写代码的时间越来越少,半年下来感觉技术毫无成长,接下来该怎么办呢?
该同学的问题十分常见,而这里真正的问题是:程序员转型管理后,如何平衡技术及管理的精力投入。
然后看最后一句“技术毫无成长,接下来该怎么办”,这里是第二个问题:为什么技术Leader不写代码会感到焦虑?
这里围绕这两个问题开始展开。
技术大神的路线
“学而优则仕”这句话在技术界也行得通,技术好的人会被尊称为大神或者大佬,他会受到技术人员天然的尊敬,这种大神光环所带来的势能对他后续工作开展有莫大的帮助,即:
- 技术好可以获得莫大的个人成就感;
- 技术好可以获得极大的势能,对实际工作有莫大的帮助;
综上,技术好对个人来说是双倍快乐!所以大家会对他沉迷不以,一旦没有成长当然会陷入焦虑。但技术好的背后有两个重要问题:
- 时间成本
优秀程序员谁都喜欢,但技术好这个事情从来都不是那么简单,他需要耐得住寂寞。
因为单就基础知识如操作系统、数据库、算法,一套连招下来很多人三年都搞不明白;到后面工作中的各种疑难杂症,如性能问题、并发问题、复杂架构的维护问题,精通其中任何一个领域,都需要投入长年累月的时间,有些领域光是时间投入还不够,还必须有对应场景,所以成为一个技术好的程序员其实很不容易!
但是技术好并不意味着工作好或者产出好,因为长年累月的跟代码打交道,在与人交流方面会有一些小毛病,甚至一些程序员会被认为是一朵奇葩;
另一方面因为大量时间投入到了技术研究,对业务的理解会打折扣,甚至一些技术人并不想要关注业务实现,这些都极大的制约了其真实的产出能力。
- 专业壁垒
除了大量时间成本外,技术本身也是分领域的,除了少数大神,程序员都是在某一块专精,比如后端、前端、iOS、Android...
精通后端后能不能也精通前端?当然可以,但再学一个端口的边际收益太低,比如后端架构师待遇已经很高了,再多获取一个前端架构师的title收益不大,多数程序员并不想做这个事情。
另一方面时间是有限的,你写后端代码的同时没有办法写前端代码,所以多数技术人员只会选择一个领域重点发展,除非那个领域不行了,不得不转方向。
这也是很多技术Leader面临的问题,技术体系旁枝错节,很难全部精通,这就是所谓的专业壁垒,因为收益太低,一般人不会选择去突破。
- 发展选择
如上所述,成为技术大神的代价是大量的时间投入,长时间的面对代码也会导致思维方式的改变,最终的结果就是对真实世界的认知不够全面。
另一方面,技术领域本身又会细分,多数人只能精通其中一块,要想职业生涯更进一步当然就会有取舍,技术专家与技术Leader两个路线选择就出现了:
- 程序员到某个阶段一些会采取纵向深耕,比如Android方向同学,可以在音视频领域深耕,这种做得深了会成为领域专家待遇很高,但问题是可能以后的路很窄;
- 另一方面一些同学会采用横向的方式扩展自己的价值,比如转技术管理,或者变成业务专家,这个选择的问题就是技术很难再进一步了;
凡事有利有弊嘛,成年人的世界总是存在取舍,但两种选择都是常见的出路。
真假Leader
从赛道来说,是这样的:
- 程序员->技术组长->技术专家->领域技术专家;
- 程序员->技术组长->技术经理->技术总监->CTO;
技术经理是个很大的分叉口,到这里多半知道自己适合什么,一些技术经理在工作一段时间后发现自己不能适应,便会回归技术路线,到技术总监后再转技术专家的还是比较少。
回到粉丝案例:刚从技术经理进阶到技术总监,所以他事实上还是技术经理思维,在这个阵痛期没有感受到总监带来的好处,更多的是发现自己的核心技术竞争力在丢失,所以感到是否焦虑。这里就引发了一个问题:
技术经理和技术总监有什么区别?
技术经理也是我们常说的一线Leader,是第一个真正具有汇报关系的Leader,一般规模在十人左右,这种小组有个特点:技术经理就算技术不是最好,但总体还是能服众的。
对于程序员来说,技术好坏直接关乎待遇,所以大家都愿意跟着技术好的Leader学习,技术不好在团队里是站不住脚的,技术强弱直接关乎话语权之争,也是因为如此,技术经理会很注重自身的实力成长。
技术经理的工作比较简单,多是带领小团队处理具体项目,可以是技术项目也可以是业务项目,经理和一线的关系更像是带着他们一起干活。
我们一般不认为技术经理是真正的Leader,因为他们是不具有资源分配权限的。
总监之于经理表面的不同是管理规模变大了,根本的不同是总监开始掌握了团队资源分配权限,并且需要处理的问题更加复杂了,所以技术经理与技术总监主要区别有两点:
- 总监开始涉及资源分配问题;
- 总监需要处理的场景更加复杂;
这里再次回到Leader的能力模型和Leader的五件事:
此图可以更好的说明区别:
- 总监需要做团队接下来的目标设计;经理更多关注下派任务;
- 总监需要做团队梯队建设;经理更多关注自身能力提升;
- 总监需要向上管理拿资源、分配资源;经理更多关注具体任务资源够不够;
- 总监需要开始尝试使用机制流程解决全局问题;经理更多关注具体问题的处理;
从Leader的五件事的设计上,就没有要求总监一定要写太多代码,而是要有全局视野,并开始思考降本增效的问题了。
所以,技术经理职位更多的是一个缓冲带,程序员可以在这个时间窗口找到自己到底适合做什么。
双线并修
至此,就可以聊聊“技术管理双线并修”问题了。
如前所述:技术是存在专业壁垒的,你是因为某个技术领域做的出色才被提拔成了总监级Leader,而已经选择了总监管理路线,自然就不能走领域专家路线,那么这个场景下你是要并修什么?
- 后端出身的技术总监,非要去教前端Leader做事,这不合适吧?
- 前端出身的技术总监,几年没写代码了,非要去跟前端Leader讨论Backbone多么优雅,这有必要吗?
这里想要表达的是什么呢?这里想要表达的是大家不要总想去做简单的事,不要在熟悉的领域逼逼赖赖,那很遭人烦,因为那是降维使用,这个是一个常见现象:很多大Leader看见一线的工作就眼红:
可以在几个小项目上打出超预期的战斗,或者扶大厦于将倾,在某个“烂尾”项目做兜底,这样很容易引起大家的注意。
但将简单的事情做得超出预期,似乎并不是我们应该做的,巴西打国足一个5:0也并不值得骄傲;湘北打败王者山王后被爱和秒杀,只能说残血被收割了,并不能说爱和多么牛逼。况且,简单的事本是别人的经验包...
有些leader定位不清晰喜欢抢下面同学活干,这种行为能带来「巨大的安全感」,这种安全感甚至是「可触摸的」:
技术总监过于专注技术细节,多半是在寻找安全感,缓解焦虑...
总监的“技术提升”
既然选择总监这条路,那么就要做这条路上的“技术突破”,可以使用以终为始的方法,看看技术负责人的能力要求是什么,就我现在的认知,要求有二:
- 成本中心
技术负责人最重要的工作是让其他CXO理解、认可并且支持技术部的工作,否则作为成本部门,在公司的地位会很低。
- 技术创新
光是让其他部门理解还不行,技术还需要创造价值,所以需要做技术创新。
上面的两个描述不够具体,走技术总监路线的同学需要不停的反问自己一个送命题:
技术部对于公司的价值是什么,与外包团队有何不同;
如果一时间没有太好的答案,那么以下问题需要先进行解答:
- 迭代速度真的不能再快了?
- 工程、技术重构类项目的价值阐述?
- 如何降本增效?
- 如何在高管会上说人话,如何让其他部门不会认为我们是工具人?
- 在高管会上,除了这个BUG我下去处理以及资源问题我去想办法外,还有什么可以聊的?
- 可不可以在不写需求的情况下完成项目?
- 技术团队的产出如何量化?
- 技术部的话语权如何提升?
- ...
拜托了各位,真的想要技术提升,请解答以上问题,不要老是盯着几个技术问题秀操作,来咬点硬的!
技术是个成本部门,并没有自己的产品,也不带流水!因此,技术部门虽然不可或缺,却未必非常重要,这也是很多技术总监会面临的一个问题:
多数时间去写代码了,却对代码要解决什么领域的问题不够敏感,很容易沦为工具人。
而高管会议时,你说的性能优化、模块重用、效率提升天老爷才感兴趣呢?甚至个别同事连研发和IT都分不清,这还如何玩耍?
做什么创新?
技术的价值在于场景应用,但创新的底色是足够的信息输入,如果技术总监对业务思考较少,对业务场景化创新完全没想法,这就很难了!
走出代码世界,更多的参与真实世界,多见一见业务的发展和困难,是技术第一梯队最需要做的事情。
一切能够被代码化和算法实现的,我们都应该去关注,任何能被技术解决的问题都应该优先考虑技术,这里具体的一些场景可以是:
1)我们能不能根据技术手段比如爬虫,拿到用户的数据,给不同的用户打不同的标签,对几百万用户做一个分层管理,有了这个分层和标签系统后,产品端再针对不同类型的用户提供不同的定制服务,标签、分类做得好,才可能做出精准的千人千面服务;
2)一些数据打通成本很高,技术上能不能协助打通,比如公安系统与业务系统(酒店系统、银行系统),我们能通过人脸识别,精准的知道这个用户到底是谁,在哪从事什么工作,再做进一步产品设计;
3)AI化可以替代哪些人工的工作,可以替代这些人工工作到什么地步,是部分替代增加效率,还是完全替代降低成本,当前每次交易成功都有百分之多少的人工成本,技术能将这个成本降低到什么程度?
4)...
以上的任务都要求对业务足够的了解,并且具备独立思考能力。
对于技术部如果所有的需求都是来源于外部团队,接到需求就做,如果出错了,再不停打补丁,没有自己的思考,不能提前6个月甚至12个月布局业务所需的技术,这种后置的成本很高。
对于业务,技术这块到底有什么核心优势?这个需要好好的面对。
不能总是去做很多短线操作,比如:做一些技术重构,在稳定性上发发力,然后再招一点人在做下工程建设,搞搞Devops嘛,最后质效数据是好看了,想来好像确实是解决了一些焦虑。但做加法,不面对自己,出来混,终究要还的。
选择总监路线就要思考技术核心竞争力到底是什么,在公司的分工和定位到底是什么,不要去找一些短线操作,以为能够有捷径,这个没有意思,而且长期的看,也确实不会给公司留下什么有价值的东西。
慢慢的回归到日常工作、业务日常,去做那些最艰难但最有意义的事情。无非就是从一个技术,转型成一个技术产品或者业务技术。每天去跟产品开一次产品会,去帮他们调调需求,就静下心来去好好做。
真的做了这步,发现路还挺长的,要转型其实还挺多的。
面对困难,就如张艺谋所说”接受是我最大的哲学,先接受,再谈创新改变“
业务架构师就是这个场景下的产物,即⼀个优秀的技术站在业务⻆度思考问题,扮演部分产品、运营⻆⾊,站在⼯程效率⻆度与产品业务⽅⼀起解决实际问题。
说白了就是——结合业务做技术创新...
业务是信息输入是底色,技术是创新能力,底色+能力=创新的可能
其实从个人发展来说,也不外如是:
1)更大的认知
比如,之前管50人团队,现在能管500人团队。
2)更多的认知
比如,之前做了两年开发,又去做了两年产品,再去做了两年语文老师。
3)1+1>2的认知
比如,两个相关联的领域,先做了两年技术,然后做了两年产品,最后成为一条业务线负责人。
这里比较晦涩,举个不恰当的例子是,学了九阳神功,又学了九阴真经,最后达到了1+1>2的效果,Hybrid就是这类产物。
业务工程师便是要融合业务与技术两个领域,设计出更好的结果,这里的输入是业务及技术知识,产出可以是产品、服务、合作流程、合作机制等。
最后总结一下:既然选择了技术总监的路线,那就要放弃纯粹的代码技术,拥抱更复杂的业务技术,创造更多的价值。
好了,今天的分享就到这,喜欢的同学可以四连支持:
想要更多交流可以加我微信: