叛徒CTO：管理和技术其实都不重要

前两天粉丝群发生了一次关于管理重大还是技术重大的讨论，其中有个大哥的观点很不错：

管理重大还是技术重大？

我觉得从企业的投资者角度，有一个例证是上市公司的营业成本里面的三费：销售费用、管理费用、研发费用。

研发费用占比高，会被认为是一个好指标，预示着企业的长期竞争力在加强；相反管理费用和销售费用高，说明企业的经营效率不高。

从这个角度，技术是优于管理的。随后他给出了进一步理解：

对于个人价值而已，我认为管理能力一般是在个人专业能力上的杠杆价值。

如果你的专业市场价值不高，那管理能力带来的个人估值提升也不会很大。纯粹的职业经理人，实则是贬值的

随后他举了一个例子：网传字节从阿里把周畅挖过去，从年薪200万涨到千万，职级4-2很高，但是钱是给在管理scope上的吗？很可能不是，是由于人家的技术专业能力。

对于他的观点，我十分认可，于是也加入了讨论：

如果公司为一个技术人给出了极高的定价，其缘由肯定不是为了管理。以字节而言肯定是买的周畅在大模型一块的认知。

在市场中，一个正常人，在管理上不会有多高价格，都是你过往公司加注在你身上的额外技术或者行业加成，他们买的是认知，买的是Know How。这是一种典型的资源换时间的表现。

由于是买的认知、买的是时间、买的是保险。

所以这类选手会面临另一个问题：我满足了你极高的溢出定价的需求，如果接下来一段时间，你没有产出，那么我会很难办！

于是他们接下来，需要面对高预期下的各种压力，如果自身不是很硬，那后面的日子会超级悲伤。

这个案例，变相给许多专注于做技术或者做管理的同学提了个醒：

• 技术不重大；
• 管理也不重大；

技术在行业的实践，他很重大！

一、100W，买了什么？

所以，各位技术专家、管理高手千万不要死抓着通用技能不放，那并没有什么竞争力。

纯管理意义不大，更多属于项目管理的一部分；纯技术更仅仅是实现目标的工具。

大家努力的核心还是要围绕行业项目做展开。所有高薪，全部是由于你的Know How，深入理解行业，做几个有壁垒的行业项目，这个事情很关键。

管理是内功心法，行业知识是实战技巧，两者缺一不可：

• 管理知识解决的是人员规模上来后的信息失真，目标不一致等问题；
• 行业知识解决的是关键瓶颈问题，也就是评价的核心；

这里话题进一步衍生：

公司CTO年薪100w，下面4个总监分别年薪60w，有什么问题是总监不能完成必须要CTO出手的吗？

答案是没有，所有CTO能做的事情，多半总监都能做，那这种情况下为什么公司还愿意给他那么高的工资呢？

答案是一点两面：

• 核心点买的是CTO在专业度上的认知；
• 他包含两个方面：忠诚度和专业度；

第一是买个专业忠诚度，也就是CTO做技术决策的时候，在关键时刻会跟公司站在一起，会帮公司省钱。

1、专业忠诚度

这个专业忠诚度，对许多同学可能比较陌生，我这里举个例子：

当前项目有2条实现路径：

• 一条与技术相关性很大，做了在技术侧会有长足的进步，但可能会花不少额外的成本；
• 另一条与技术相关性不大，但也能解决问题，成本会降低不少；

想象一下你是那个CTO，面对技术的极致追求，在4个技术总监的不停撺掇之下，能不能做出最有利于公司的决策？

这是一个很重大的问题。

这里举个真实例子：之前在一家大公司的时候，部门负责人极度迷信flutter这个技术，想要推动用Flutter重构公司APP。

于是他先在团队内做验证，大致花了10多个人做了半年，成本的话大致300w左右，年底自然是无疾而终。

但谁应该为这300w买单呢？

要注意的是，这里当然不是说不该做技术创新，管理不能从一个极端到另一个极端。

只不过在各个公司中，有些技术基建是浪费，有些技术基建是必须，什么是浪费什么是必须，是需要技术一号位去判断的。

作为技术一号位第一要端正态度，自己第一是公司高管，其次才是一个技术人，屁股一旦坐歪，造成的浪费可就大了；

以上是忠诚度问题，其次是专业能力问题。

2、专业能力的gap

这里的专业能力不是你实际掌握的能力，而是公司需要的能力，而两者总是不匹配的，这变相对CTO增加了两个要求：

• 第一，快速学习的能力，自己很快就能掌握；
• 第二，优秀的资源渠道，自己能快速找到掌握能力的人；

为什么这么急迫的需要CTO掌握公司需要的专业能力呢？

一方面是由于公司不愿意为第二个人付出如此高的专业忠诚度价格；

另一方面，业务在发展，任何一个需要专业判断的地方出点问题，都会导致浪费的发生。

所以，CTO的专业力，如何是如何体现的？

3、专业能力如何体现

CTO专业能力的体现，一般以提出问题的方式进行。

提个好问题的本质是评价一个事物本身，最优评价能力不在于对已有结果进行评价。

而要找到事物隐藏起来【看似不存在那部分】，其次是找到【多出来的部分】，也就是【正确但没用的部分】。

正确的评价会减少公司许多无效浪费，属于技术一号位的基本功。

最后一个问题衍生：不懂技术能做CTO吗？

二、CTO需要懂技术吗

不懂技术能做CTO吗？有些同学认为可以，有些同学认为不可以。

但马上有2个同学打破了僵持：实际上已经有2个产品成为CTO的真实案例，并且他们还做得挺好的！

所以结论是：不懂代码也能做CTO，由于懂技术和懂代码完全是两回事，列如：

• 前端同学往往不会后端代码；
• 后端同学会对Native代码感到陌生；
• 就算有全栈高手，面对新出的AI技术，依旧需要再学习；

所以就算技术出身的CTO，也不见得对技术有全面的认识。

而全栈技术本来就很难，花大量时间成为专家，但管理能力不行，业务理解跟不上，这种人是很难成为CTO的。

综上，不能以懂代码作为懂技术的衡量标准，那么应该用什么作为懂的衡量标准呢？

我认为面对一件事情/任务的时候，有三点要思考：

• 对于这个问题已经提出的动作，或者完成的工作，能不能提出问题。许多人对这个事情/任务毫无概念，连最基本的问题都提不出来；
• 提出正确的问题是为了引导负责人思考，这需要我们对事情/任务有好坏的标准的基本认知，也就是知道什么是好坏；
• 最后，如果这个任务有问题，你是否具备指导的能力；

列如，大家遇到一个问题，有几点可以看出我们对问题是不是清晰：

• 第一，我们能不能对问题提出清晰的观点，有观点才有认知；
• 第二，对于我们提出的观点，我们是否有足够的论据，或者知道要找什么论据，进一步去哪里找；
• 第三，有其他同学提出了我们没想到的论据，我们能否判断这个论据的真假，以及与我们的论点是否有直接的关系；
• 最后，有些论据不完善，我们是否有能力进一步去完善他；

所以，什么是懂（一件事/一个任务）？

第一，你对这件事/任务会有一个清晰的衡量标准，你能明确定义他的好坏，并且这个好坏能被专业的人所认可；

其次，你的衡量标准是可衡量、可进一步拆分的，甚至可以形成一个判断模型；

然后，对于一个已经存在的任务，你能根据衡量标准，清晰的指出他哪里有问题；对于一个需求去完成的任务，你能毒辣的指出，他哪些部分是多余的，不需要做的！

最后，对于那些有问题的部分，你能提出进一步的优化提议。

综上，你如果对一件事有标准、能揪出问题，有修改意见，对于这件事毫无疑问你是懂的！

三、结语

企业愿意为个人支付高额溢价，从来不是由于他能写多少行代码、管理多少人。

而是由于他具备能快速对问题做出精准判断的Know How，这里可以是专业问题、也可以是行业问题，同时可以是管理问题。

所谓Know How也不神秘，不过是懂不懂的另一种表达。

这种“懂不懂”，不只是会不会某项技术，也并非单纯的管理方法论，而是能否在复杂的业务场景下提出恰到好处的问题，明确标准，剖析实质，并指明真正有价值的解决路径。

如果不能也没关系，但你得具备快速能的学习能力！

当能不能提出好的问题上升为衡量懂不懂的标尺时，它本身已是Know How的有机体现。

它意味着你不仅熟悉业务，还能洞穿技术与管理手段背后的本质逻辑。

公司出高价买的，正是这种能缩短试错时间、降低决策风险、提高资源利用率的“行业Know How”。

PS：管理也可以认为是一个行业，列如管理咨询行业

换言之，在技术与管理的交汇点处，真正引领公司向前的，是那些真正懂得“问题核心”、拥有实战认知与判断标准的人。

作者丨叶小钗

来源丨公众号：叶小钗（ID：erchonglin）

dbaplus社群欢迎广大技术人员投稿，投稿邮箱：editor@dbaplus.cn