职业和人生的选择有很多，你可能不需要成为一个 CTO，但是你不能失去选择成为一个 CTO 的自由;你可以不去做一个 CTO，但是你依然应该拥有成为 CTO 的能力。
你可能不需要成为 CTO
先讲个段子
一个乞丐和一个富翁在海边沙滩上晒太阳，乞丐问富翁：你是怎么成为富翁的?富翁说：努力工作挣钱，然后投资做生意，慢慢积累财富，就会成为富翁了。乞丐又问：成为富翁以后呢?富翁说：我就可以到海边沙滩上晒太阳了。乞丐想了想说：我已经在海边沙滩上晒太阳了，我不需要努力挣钱。
今天跟大家分享的题目是“你可能不需要成为 CTO”，想表达的也是这样一个意思：职业和人生的选择有很多，你可能不需要成为一个 CTO，但是你不能失去选择成为一个 CTO 的自由;你可以不去做一个 CTO，但是你依然应该拥有成为 CTO 的能力。
在这里，我会和大家分享一个模型，一个故事，一个定律;分享关于工程师提升专业技能、高效解决问题的一些业界研究成果，揭示一些职场规律，以及我为什么要说“你可能不需要成为 CTO”。
德雷福斯模型
德雷福斯模型是一个技能获取模型，将人们学习掌握一个技能经历的阶段分为新手、高级新手、胜任者、精通者、专家。
德雷福斯模型
新手在特定的技能领域很少或没有经验，必须在准确的指令或者别人的帮助下才能工作。这里的经验指：通过持续强化的训练和思考，促进思维的不断转变。
我曾经在招聘中见过很多号称拥有十年工作经验的人，但是看他的简历，发现他工作***年的项目难度、工作职责和十年后的难度职责几乎没有什么变化。这样的工作经验被称作 10 *1 年工作经验，对技能的提升并没有多少帮助。
经过基本的训练后，新手就进入高级新手阶段。处在这个阶段的人们，掌握了完成任务的规则并能多少突破规则的限制，可以尝试独立完成任务，但并不能真正解决问题。
他会寻找完成任务的方法，但是很少去追根问底。他并不理解自己所做的事情在整个大环境中所处的地位和影响。
专家是特定技能领域知识的创造者，信息的主要来源。他们拥有丰富的经验并能在具体的环境中准确应用经验，他们不断寻找新的更好的方法去做事。
他们著书立说，巡回演讲，开发新的技术框架，研究新的开发模式，带领整个行业不断向前进。
如果说高级新手基于规则做事，那么专家就是在基于直觉做事，他们本能地能感知到最合适的解决方案，敏锐地感受到新出现的技术火花所蕴藏的美感和力量，并能找到最恰当的方式去推动和执行。
但是遗憾的是，在大多数技能领域，并不是只要工作时间足够长，就能够自然进化到专家阶段。
事实上，大部分人终其一生，都将停留在高级新手阶段，而只有极少数的人能到达专家阶段。
更加让人沮丧的是，大多数高级新手其实并没有意识到自己是高级新手，也就是所谓的二阶不知道，即不知道自己不知道。
完成从新手到专家的历程，需要高强度的专业训练，即所谓一万小时定律。每一次在现有基础上，你需要去完成更有挑战的任务，训练自己的专业技能，实现思维的转变。
在软件开发这样一个快速发展的技能领域，要成为一个专家，至少需要十年的时间，所以很遗憾地说，那些认为三十岁以后不能编程的同学，几乎没有可能成为软件开发方面的专家。
你的灯亮着吗
我们上面提到，高级新手并不能真正解决问题，其根源在于高级新手很少去真正思考问题，他关心的是如何去完成手头的任务，并不关心这个任务真正要解决的问题是什么。突破高级新手限制的一个重要手段就是去思考问题本身，而不是仅仅专注完成任务。
讲一个小故事
北欧有一个度假胜地，是欧洲人夏天避暑度假的好去处，在去往度假胜地的必经之路需要经过一个长长的隧道，隧道的工程师为了保证在隧道偶尔停电的情况下，隧道能安全使用，在隧道入口处立了一块牌子，写着：请打开车灯。
游客们开着汽车，打开车灯，穿过隧道，到达度假胜地，快乐地去玩耍了。而等他们要回去的时候，有些人却发现车子无法启动——他们忘记关闭车灯，汽车电池耗尽了。
小镇的警察们只好开着自己的警车四处为游客们充电，疲惫不堪。而沮丧的游客们则在回去以后四处抱怨，分享他们糟糕的旅游经验，导致小镇旅游业大受影响，镇长压力山大。
于是人们找到隧道的工程师，要求他在隧道的尽头再立一块牌子，写上：请关闭车灯。工程师照做了以后，却发现麻烦来了：夜晚穿过隧道的游客看着这样一块牌子，一脸懵逼。
这个场景是不是和工程师们日常的工作场景很相似，总有客户、老板、产品经理过来跟你说，这里需要这样一个按钮，那里需要这样一个功能。
你照做了以后，发现只是导致了更多的麻烦，你不是在解决问题，而是在制造问题。
回到这个故事，我们重新思考一下：这是谁的问题?谁能够解决这个问题?如果这是镇长的问题，那么能不能让镇长在停车场修建充电桩让游客们充电?
如果这是警察的问题，那么能不能安排专门的警察巡视停车没关车灯的游客，提醒他们关闭车灯。
如果这是游客的问题，能不能在隧道出口立一块牌子，写上：你的灯亮着吗?提醒他们问题的存在，让他们自己去解决问题。
也许这是***的方法，你不需要急着帮别人解决问题，也许你费了九牛二虎之力要解决的问题，当事人轻轻动下手指就能解决。而你要做的，仅仅是告诉他问题的存在。
所以，亲爱的工程师们，你在每次解决问题的时候，是否想清楚了问题的本质究竟是什么，这是谁的问题，谁能解决这个问题，你在为谁解决问题。
作为一个工程师，如果只是听从别人的指令执行解决方案，那么很多时候你是在制造问题，而不是解决问题，你加班加点辛苦工作只是在为公司制造麻烦。
而对于你自己而言，日复一日重复执行解决方案，距离你成为一个专家也越来越远。
彼得定律
在一个成熟有效的组织中，当一个员工在其岗位能够出色完成工作，就会得到晋升，被提拔到更高一级职位。
如果在这个职位，他能够继续出色完成工作，他就会继续得到晋升，直到他晋升到某个职位以后无法出色完成工作为止。
彼得定律
在一个层级组织中，每个员工都会趋向于晋升到他所不能胜任的职位。
当一个人位于他不能胜任的职位上时，他必须投入全部的精力才能有效完成工作，这个职位被称作这个人的彼得高地。
一个处于彼得高地的人，精疲力尽于他手头的工作，无法再进行更进一步的思考和学习，将止步于他当前的德雷福斯模型阶段。
所以，一个人在职业生涯中能够晋升的***职位，能够在专业技能上进化的***阶段，依赖于他的专业能力和综合素养，依赖于他拥有的持续学习和专业训练的条件与环境。这和他晋升的速度无关，有时候也许恰恰相反。
所以如果你没有做好准备，也许你不需要成为一个 CTO。
好了，聪明的你，一定已经明白我们这次主题想要表达的意思：
- 对公司而言，真正有价值的是你为公司解决了多少问题，而不是完成了多少工作，工作本身没有意义，解决问题才有意义。
- 对于你自己而言，真正有价值的不是你获得了多快的晋升速度、多高的加薪，而是你获得了多少持续高强度训练的机会。而这两者，本质上是统一的。
***小编给大家分享一篇旧文，或许会对正处于技术创业的你有所启发。
今天有朋友在微信里让我给推荐一个 CTO。说是一家公司在找人，据说「项目不错」，因为之前的业务不是很互联网，现在有一个新的项目要做，要做一个社会化电商的社区，类似一个国外的某某网站，所以他们说需要一个 CTO ，问我是否有人选推荐。
他们可能并不需要一个 CTO ，原因有如下几个：
- 对类似的社区类产品来说，技术可能并不是最重要的，当然我不是说技术完全不重要，只是重要程度没有想象的那样。实际上搭建一个论坛随便一个工程师也能做。
- 针对这个产品来说，要做成需要很强的运营能力，换言之，需要花大力气去找这方面的人才而不是找 CTO。
- 如果运营不够强，或者根本都没意识到这问题，找到 CTO 也没用。
- 如果这家公司只是想尝试一下这个产品，产品是否可行都说不准，一个具备 CTO 能力的人为什么要跟着你玩? 产品做不成的话，CTO 干嘛去?
- 如果有人只对 CTO 这个职位感兴趣，而不考虑上述其他几个原因乃至更多我还没提到的原因，这样的人也没什么判断力。
- 基于如上原因，不能推荐。建议找个能搞定事情的技术经理先做一下。
有人说，你这是跟人家逗哏还是抬杠呢??别闹，我当然是很严肃的在探讨问题。很多嚷嚷着找 CTO 的公司其实并不需要一个 CTO。
以下几个阶段就不一定需要一个 CTO：
- 业务根本没得到验证的时候，或是准备克隆一个国外的一个产品，模式一定可行么?
- 团队很小的时候也不一定需要 CTO 。早早的任命 CTO ，如果他能力不能随着团队壮大而拓展，对团队就是一种损害，所以***还是用「技术负责人」这样的称呼比较合适。
- 有些初次创业的人觉得自己有个好点子，想找个合伙人，但是自己又找不到(这句话很关键，为什么他自己找不到?)，于是到处求爷爷告奶奶拜托朋友帮找技术合伙人或是 CTO ，基本没戏。
以下这几种情况，CTO ***不要跳入火坑：
- 土鳖老板看着互联网眼热，觉得这玩意儿好像好赚钱，想投资几百万试试看，但自己又不懂技术，于是想找个懂技术的来补课。
- 受投资方委托进入创业团队，团队内部本来又矛盾重重。
- 创始人用不光彩的手段逼走前任 CTO。新加入一个公司做 CTO，***问问前任怎么走的。
***给大家的建议是：创业团队别总盯着头衔找人，而要找能解决问题的人，把你的事情搞定。
当然，前提是你已经识别出自己团队最需要什么样的人，最缺少什么样的资源，最需要解决什么样的问题。如果这些你根本不知道，那么你***找一个 CEO 吧…
CTO 并不是一个多么值得争取的职位，职位不重要，重要的是你做什么，解决了什么问题。要知道，很多年前，每个工程师还都想做架构师呢。
