关注公众号回复1
获取一线、总监、高管《管理秘籍》
前两天粉丝群发生了一次关于管理重要还是技术重要的讨论，其中有个大哥的观点很不错：
管理重要还是技术重要？
我觉得从企业的投资者角度，有一个例证是上市公司的营业成本里面的三费：销售费用、管理费用、研发费用。
研发费用占比高，会被认为是一个好指标，预示着企业的长期竞争力在加强；相反管理费用和销售费用高，说明企业的经营效率不高。
从这个角度，技术是优于管理的。随后他给出了进一步理解：
对于个人价值而已，我认为管理能力一般是在个人专业能力上的杠杆价值。
如果你的专业市场价值不高，那管理能力带来的个人估值提升也不会很大。纯粹的职业经理人，其实是贬值的
随后他举了一个例子：网传字节从阿里把周畅挖过去，从年薪200万涨到千万，职级4-2很高，但是钱是给在管理scope上的吗？很可能不是，是因为人家的技术专业能力。
对于他的观点，我十分认可，于是也加入了讨论：
如果公司为一个技术人给出了极高的定价，其原因肯定不是为了管理。以字节而言肯定是买的周畅在大模型一块的认知。
在市场中，一个正常人，在管理上不会有多高价格，都是你过往公司加注在你身上的额外技术或者行业加成，他们买的是认知，买的是Know How。这是一种典型的资源换时间的表现。
因为是买的认知、买的是时间、买的是保险。
所以这类选手会面临另一个问题：我满足了你极高的溢出定价的需求，如果接下来一段时间，你没有产出，那么我会很难办！
于是他们接下来，需要面对高预期下的各种压力，如果自身不是很硬，那后面的日子会非常难过。
这个案例，变相给很多专注于做技术或者做管理的同学提了个醒：
技术不重要； 管理也不重要；
技术在行业的实践，他很重要！
100W，买了什么？
所以，各位技术专家、管理高手千万不要死抓着通用技能不放，那并没有什么竞争力。
纯管理意义不大，更多属于项目管理的一部分；纯技术更仅仅是实现目标的工具。
大家努力的核心还是要围绕行业项目做展开。所有高薪，全部是因为你的Know How，深入理解行业，做几个有壁垒的行业项目，这个事情很关键。
管理是内功心法，行业知识是实战技巧，两者缺一不可：
管理知识解决的是人员规模上来后的信息失真，目标不一致等问题； 行业知识解决的是关键瓶颈问题，也就是评价的核心；
这里话题进一步衍生：
公司CTO年薪100w，下面4个总监分别年薪60w，有什么问题是总监不能完成必须要CTO出手的吗？
答案是没有，所有CTO能做的事情，多半总监都能做，那这种情况下为什么公司还愿意给他那么高的工资呢？
答案是一点两面：
核心点买的是CTO在专业度上的认知； 他包含两个方面：忠诚度和专业度；
第一是买个专业忠诚度，也就是CTO做技术决策的时候，在关键时刻会跟公司站在一起，会帮公司省钱。
专业忠诚度
这个专业忠诚度，对很多同学可能比较陌生，我这里举个例子：
当前项目有2条实现路径：
一条与技术相关性很大，做了在技术侧会有长足的进步，但可能会花不少额外的成本； 另一条与技术相关性不大，但也能解决问题，成本会降低不少；
想象一下你是那个CTO，面对技术的极致追求，在4个技术总监的不停撺掇之下，能不能做出最有利于公司的决策？
这是一个很重要的问题。
这里举个真实例子：之前在一家大公司的时候，部门负责人极度迷信flutter这个技术，想要推动用Flutter重构公司APP。
于是他先在团队内做验证，大概花了10多个人做了半年，成本的话大概300w左右，年底自然是无疾而终。
但谁应该为这300w买单呢？
要注意的是，这里当然不是说不该做技术创新，管理不能从一个极端到另一个极端。
只不过在各个公司中，有些技术基建是浪费，有些技术基建是必须，什么是浪费什么是必须，是需要技术一号位去判断的。
作为技术一号位首先要端正态度，自己首先是公司高管，其次才是一个技术人，屁股一旦坐歪，造成的浪费可就大了；
以上是忠诚度问题，其次是专业能力问题。
专业能力的gap
这里的专业能力不是你实际掌握的能力，而是公司需要的能力，而两者总是不匹配的，这变相对CTO增加了两个要求：
第一，快速学习的能力，自己很快就能掌握； 第二，优秀的资源渠道，自己能快速找到掌握能力的人；
为什么这么急迫的需要CTO掌握公司需要的专业能力呢？
一方面是因为公司不愿意为第二个人付出如此高的专业忠诚度价格；
另一方面，业务在发展，任何一个需要专业判断的地方出点问题，都会导致浪费的发生。
所以，CTO的专业力，如何是如何体现的？
专业能力如何体现
CTO专业能力的体现，一般以提出问题的方式进行。
提个好问题的本质是评价一个事物本身，最优评价能力不在于对已有结果进行评价。
而要找到事物隐藏起来【看似不存在那部分】，其次是找到【多出来的部分】，也就是【正确但没用的部分】。
正确的评价会减少公司很多无效浪费，属于技术一号位的基本功。
最后一个问题衍生：不懂技术能做CTO吗？
CTO需要懂技术吗
不懂技术能做CTO吗？有些同学认为可以，有些同学认为不可以。
但马上有2个同学打破了僵持：实际上已经有2个产品成为CTO的真实案例，并且他们还做得挺好的！
所以结论是：不懂代码也能做CTO，因为懂技术和懂代码完全是两回事，比如：
前端同学往往不会后端代码； 后端同学会对Native代码感到陌生； 就算有全栈高手，面对新出的AI技术，依旧需要再学习；
所以就算技术出身的CTO，也不见得对技术有全面的认识。
而全栈技术本来就很难，花大量时间成为专家，但管理能力不行，业务理解跟不上，这种人是很难成为CTO的。
综上，不能以懂代码作为懂技术的衡量标准，那么应该用什么作为懂的衡量标准呢？
我认为面对一件事情/任务的时候，有三点要思考：
对于这个问题已经提出的动作，或者完成的工作，能不能提出问题。很多人对这个事情/任务毫无概念，连最基本的问题都提不出来； 提出正确的问题是为了引导负责人思考，这需要我们对事情/任务有好坏的标准的基本认知，也就是知道什么是好坏； 最后，如果这个任务有问题，你是否具备指导的能力；
比如，大家遇到一个问题，有几点可以看出我们对问题是不是清晰：
第一，我们能不能对问题提出清晰的观点，有观点才有认知； 第二，对于我们提出的观点，我们是否有足够的论据，或者知道要找什么论据，进一步去哪里找； 第三，有其他同学提出了我们没想到的论据，我们能否判断这个论据的真假，以及与我们的论点是否有直接的关系； 最后，有些论据不完善，我们是否有能力进一步去完善他；
所以，什么是懂（一件事/一个任务）？
首先，你对这件事/任务会有一个清晰的衡量标准，你能明确定义他的好坏，并且这个好坏能被专业的人所认可；
其次，你的衡量标准是可衡量、可进一步拆分的，甚至可以形成一个判断模型；
然后，对于一个已经存在的任务，你能根据衡量标准，清晰的指出他哪里有问题；对于一个需求去完成的任务，你能毒辣的指出，他哪些部分是多余的，不需要做的！
最后，对于那些有问题的部分，你能提出进一步的优化建议。
综上，你如果对一件事有标准、能揪出问题，有修改意见，对于这件事毫无疑问你是懂的！
结语
企业愿意为个人支付高额溢价，从来不是因为他能写多少行代码、管理多少人。
而是因为他具备能快速对问题做出精准判断的Know How，这里可以是专业问题、也可以是行业问题，同时可以是管理问题。
所谓Know How也不神秘，不过是懂不懂的另一种表达。
这种“懂不懂”，不只是会不会某项技术，也并非单纯的管理方法论，而是能否在复杂的业务场景下提出恰到好处的问题，明确标准，剖析实质，并指明真正有价值的解决路径。
如果不能也没关系，但你得具备快速能的学习能力！
当能不能提出好的问题上升为衡量懂不懂的标尺时，它本身已是Know How的有机体现。
它意味着你不仅熟悉业务，还能洞穿技术与管理手段背后的本质逻辑。
公司出高价买的，正是这种能缩短试错时间、降低决策风险、提高资源利用率的“行业Know How”。
PS：管理也可以认为是一个行业，比如管理咨询行业
换言之，在技术与管理的交汇点处，真正引领公司向前的，是那些真正懂得“问题核心”、拥有实战认知与判断标准的人。
