技术大神的路线
“学而优则仕”这句话在技术界也行得通，技术好的人会被尊称为大神或者大佬，他会受到技术人员天然的尊敬，这种大神光环所带来的势能对他后续工作开展有莫大的帮助，即：
技术好可以获得莫大的个人成就感；
技术好可以获得极大的势能，对实际工作有莫大的帮助；
综上，技术好对个人来说是双倍快乐！所以大家会对他沉迷不以，一旦没有成长当然会陷入焦虑。但技术好的背后有两个重要问题：
时间成本
优秀程序员谁都喜欢，但技术好这个事情从来都不是那么简单，他需要耐得住寂寞。
因为单就基础知识如操作系统、数据库、算法，一套连招下来很多人三年都搞不明白；到后面工作中的各种疑难杂症，如性能问题、并发问题、复杂架构的维护问题，精通其中任何一个领域，都需要投入长年累月的时间，有些领域光是时间投入还不够，还必须有对应场景，所以成为一个技术好的程序员其实很不容易！
但是技术好并不意味着工作好或者产出好，因为长年累月的跟代码打交道，在与人交流方面会有一些小毛病，甚至一些程序员会被认为是一朵奇葩；
另一方面因为大量时间投入到了技术研究，对业务的理解会打折扣，甚至一些技术人并不想要关注业务实现，这些都极大的制约了其真实的产出能力。
专业壁垒
除了大量时间成本外，技术本身也是分领域的，除了少数大神，程序员都是在某一块专精，比如后端、前端、iOS、Android...
精通后端后能不能也精通前端？当然可以，但再学一个端口的边际收益太低，比如后端架构师待遇已经很高了，再多获取一个前端架构师的title收益不大，多数程序员并不想做这个事情。
另一方面时间是有限的，你写后端代码的同时没有办法写前端代码，所以多数技术人员只会选择一个领域重点发展，除非那个领域不行了，不得不转方向。
这也是很多技术Leader面临的问题，技术体系旁枝错节，很难全部精通，这就是所谓的专业壁垒，因为收益太低，一般人不会选择去突破。
发展选择
如上所述，成为技术大神的代价是大量的时间投入，长时间的面对代码也会导致思维方式的改变，最终的结果就是对真实世界的认知不够全面。
另一方面，技术领域本身又会细分，多数人只能精通其中一块，要想职业生涯更进一步当然就会有取舍，技术专家与技术Leader两个路线选择就出现了：
程序员到某个阶段一些会采取纵向深耕，比如Android方向同学，可以在音视频领域深耕，这种做得深了会成为领域专家待遇很高，但问题是可能以后的路很窄；
另一方面一些同学会采用横向的方式扩展自己的价值，比如转技术管理，或者变成业务专家，这个选择的问题就是技术很难再进一步了；
凡事有利有弊嘛，成年人的世界总是存在取舍，但两种选择都是常见的出路。
真假Leader
从赛道来说，是这样的：
程序员->技术组长->技术专家->领域技术专家；
程序员->技术组长->技术经理->技术总监->CTO；
技术经理是个很大的分叉口，到这里多半知道自己适合什么，一些技术经理在工作一段时间后发现自己不能适应，便会回归技术路线，到技术总监后再转技术专家的还是比较少。
回到粉丝案例：刚从技术经理进阶到技术总监，所以他事实上还是技术经理思维，在这个阵痛期没有感受到总监带来的好处，更多的是发现自己的核心技术竞争力在丢失，所以感到是否焦虑。这里就引发了一个问题：
技术经理和技术总监有什么区别？
技术经理也是我们常说的一线Leader，是第一个真正具有汇报关系的Leader，一般规模在十人左右，这种小组有个特点：技术经理就算技术不是最好，但总体还是能服众的。
对于程序员来说，技术好坏直接关乎待遇，所以大家都愿意跟着技术好的Leader学习，技术不好在团队里是站不住脚的，技术强弱直接关乎话语权之争，也是因为如此，技术经理会很注重自身的实力成长。
技术经理的工作比较简单，多是带领小团队处理具体项目，可以是技术项目也可以是业务项目，经理和一线的关系更像是带着他们一起干活。
我们一般不认为技术经理是真正的Leader，因为他们是不具有资源分配权限的。
总监之于经理表面的不同是管理规模变大了，根本的不同是总监开始掌握了团队资源分配权限，并且需要处理的问题更加复杂了，所以技术经理与技术总监主要区别有两点：
总监开始涉及资源分配问题；
总监需要处理的场景更加复杂；
这里再次回到Leader的能力模型和Leader的五件事：
此图可以更好的说明区别：
总监需要做团队接下来的目标设计；经理更多关注下派任务；
总监需要做团队梯队建设；经理更多关注自身能力提升；
总监需要向上管理拿资源、分配资源；经理更多关注具体任务资源够不够；
总监需要开始尝试使用机制流程解决全局问题；经理更多关注具体问题的处理；
从Leader的五件事的设计上，就没有要求总监一定要写太多代码，而是要有全局视野，并开始思考降本增效的问题了。
所以，技术经理职位更多的是一个缓冲带，程序员可以在这个时间窗口找到自己到底适合做什么。
双线并修
至此，就可以聊聊“技术管理双线并修”问题了。
如前所述：技术是存在专业壁垒的，你是因为某个技术领域做的出色才被提拔成了总监级Leader，而已经选择了总监管理路线，自然就不能走领域专家路线，那么这个场景下你是要并修什么？
后端出身的技术总监，非要去教前端Leader做事，这不合适吧？
前端出身的技术总监，几年没写代码了，非要去跟前端Leader讨论Backbone多么优雅，这有必要吗？
这里想要表达的是什么呢？这里想要表达的是大家不要总想去做简单的事，不要在熟悉的领域逼逼赖赖，那很遭人烦，因为那是降维使用，这个是一个常见现象：很多大Leader看见一线的工作就眼红：
可以在几个小项目上打出超预期的战斗，或者扶大厦于将倾，在某个“烂尾”项目做兜底，这样很容易引起大家的注意。
但将简单的事情做得超出预期，似乎并不是我们应该做的，巴西打国足一个5:0也并不值得骄傲；湘北打败王者山王后被爱和秒杀，只能说残血被收割了，并不能说爱和多么牛逼。况且，简单的事本是别人的经验包...
有些leader定位不清晰喜欢抢下面同学活干，这种行为能带来「巨大的安全感」，这种安全感甚至是「可触摸的」：
技术总监过于专注技术细节，多半是在寻找安全感，缓解焦虑...
