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