为什么我始终坚持“程序员中心”

这些年，公司不断发展，团队越来越大，组织也越来越复杂。随着新人越来越多，一些我们早期反复讲过、但后来不再常提的基本认识，慢慢变得没有那么清楚了。

我越来越觉得，有些事情还是应该反复说明。不是因为它们新，而恰恰是因为它们太基础，基础到一旦不再被说起，人们就会很自然地用更常见的那套公司逻辑去理解它们。时间一久，很多角色会错位，很多做法会变形，最后连组织本身都会在不知不觉中变成另一种东西。

我一直认为，一家软件公司最根本的问题，不是管理层如何管理得更细，也不是流程如何设计得更完整，而是这家公司到底围绕谁来运转。

对这个问题，我的看法这些年没有变过：
软件公司真正的核心，应该是程序员。

这并不是一句表示尊重的话，也不是为了强调技术岗位比别的岗位更重要，而是一个非常现实的判断。因为真正面对问题、理解问题、解决问题，并最终为客户持续创造价值的人，通常就是程序员。如果一家软件公司离开了这一点，其他很多看起来完整的管理设计，最后都会失去基础。

很多公司在发展过程中，都会慢慢形成一种很自然的倾向：组织越大，支持部门越多，管理层级越多，离一线越远的人反而越容易掌握更大的解释权和决定权。久而久之，真正面对客户、承担结果的人，往往变成了被安排、被要求配合的一方。

这种现象很常见，但我始终认为它并不合理。

因为一家软件公司如果主要依靠程序员创造价值，那么组织最重要的任务，就不应该是把程序员更严密地纳入一个管理体系，而应该是让他们能够更独立、更稳定、更长期地创造价值。换句话说，组织存在的意义，不是让一线适应管理，而是让管理适应价值创造。

从这个角度看，销售、行政、运营、各类支持岗位，当然都很重要，但它们的重要性并不来自它们可以代表公司高于一线发号施令，而在于它们能够为一线创造更好的工作条件，让真正创造价值的人更顺畅地工作。

我更愿意把这种组织理解为一种平台型组织。平台的意义，从来不是把每一个参与者都纳入统一控制，而是为真正创造价值的人提供支持、规则、基础设施和风险承担。如果平台上的核心创造者失去了独立判断的空间，也失去了成长和经营的空间，那么这个平台就算流程再完整，也不会真正有生命力。

这些年，我有一个越来越强的感受：很多组织的问题，并不是因为一线不努力，而是因为支持和管理角色太容易滑向另一个位置——从服务一线，变成替一线做主。

只要一个岗位更靠近管理中枢，或者更接近流程和资源配置，它就很容易产生一种错觉：自己看得更全面，所以也更有资格决定别人该怎么做。这种心态在很多公司里非常常见，甚至会被认为理所当然。但我一直不太认同。

我更相信一个更简单的原则：谁真正面对客户，谁真正承担结果，谁就应该拥有与之相匹配的判断空间和决定空间。

原因并不复杂。责任和权力如果不在同一个人身上，事情最后往往就会变得很奇怪。表面上每个人都在参与，实际上没有人真正经营；表面上沟通很多，实际上谁都不愿意承担最后结果；表面上协调得很充分，真正接近问题的人却失去了主导权。

软件服务尤其如此。客户关系不是靠汇报关系维持的，而是靠长期信任维持的。交付质量也不是靠层层转述和审批产生的，而是靠真正理解问题的人一点一点做出来的。如果真正面对客户和项目的人没有足够的空间，组织就会越来越擅长解释，越来越不擅长创造价值。

所以我一直觉得，管理在软件组织里必须非常克制。支持当然需要，建议当然需要，协同也当然需要，但这些东西都不应该轻易变成代替一线判断，更不应该变成“我比你更懂整体，所以你照着做”。

一旦这种逻辑扩散开来，组织就会慢慢偏离它最初存在的原因。

过去很多年，软件行业里一直有一种比较稳定的分工方式：有人负责理解需求，有人负责分析业务，有人负责与客户沟通，程序员则主要负责把这些事情实现出来。这种分工在一定阶段里是有效的，但我越来越觉得，这种结构并不是软件组织真正理想的状态。

尤其是在AI快速发展的今天，这个判断变得更明显了。

AI带来的变化，并不只是让程序员写代码更快，而是让一个优秀程序员有可能更直接地理解问题、整理信息、分析业务、形成方案并推动结果。也就是说，程序员未来最重要的能力，可能不再只是“编码能力”，而是更完整的问题解决能力。

如果一个组织仍然把程序员主要放在执行位置上，中间再层层安排各种替他理解、替他表达、替他拆解问题的人，表面上看起来分工细致，实际上很可能是在削弱最重要的那个人。

程序员一旦长期只负责执行，就很难真正形成面向客户和业务的能力，也很难真正建立起自己的判断力。久而久之，他会变得越来越依赖组织中的中间层，而不是越来越接近价值创造本身。这样的程序员，也很难成为客户真正信任的长期伙伴。

所以我一直认为，好的软件组织，方向应该是让程序员越来越独立，而不是越来越被包裹。其他角色当然可以存在，但它们存在的意义，不应该是挡在程序员和问题之间，而应该是帮助程序员更直接地面对问题。

有时候也会有人问：如果总强调程序员中心，会不会忽视公司整体？会不会忽视客户？会不会把其他岗位的价值说得太低？

我并不这么看。

我理解的“程序员中心”，并不是说只有程序员重要，别人都不重要；更不是说公司利益和客户利益不重要。它真正表达的，是一种组织上的基本判断：在一家以软件开发为核心能力的公司里，程序员是价值创造的主要源头，所以组织设计必须尊重这个源头。

这其实是一种非常朴素的经营理性。

一家软件公司能不能长期做好，最终取决于它能不能持续吸引、留住并成就那些真正创造价值的人。如果程序员在组织中始终只是被安排的一方，被消耗的一方，被别人替代思考的一方，那么再漂亮的战略、再完整的流程、再精细的管理，也都只会越来越空。

相反，如果程序员能够在组织中获得足够的尊重、成长空间、利益匹配和独立性，那么客户价值才会稳定，公司才会真正健康。因为客户最终感受到的，不是你内部管理体系多么完备，而是有没有人真正理解他的问题，并持续把事情做好。

从这个意义上说，重视程序员，不是理想主义，而是对软件行业本质的一种尊重。

我这些年越来越在意的一件事，是组织的“习惯性回归”。

很多公司在创业早期，离客户近，离问题近，也更愿意相信一线的判断。但随着规模变大，组织很容易不知不觉退回到另一种更常见的状态：流程越来越多，角色越来越多，解释越来越多，真正承担结果的人反而越来越没有决定空间。

这种变化往往不是刻意发生的。它通常是以一种很自然、甚至很“合理”的方式发生的。有人会说，需要更规范一点；有人会说，需要更成熟一点；也有人会说，需要从公司整体角度统一管理。这些说法单独看都没有错，但如果最后的结果是让真正创造价值的人越来越远离判断权，那么组织其实已经偏了。

我始终觉得，一家公司最大的风险，很多时候不是外部竞争，而是内部慢慢形成一种新的共识：管理比创造价值更重要，协调比直接解决问题更重要，离中心近的人比离客户近的人更重要。

如果一家软件公司真的走到了这一步，它即使还在增长，也已经开始失去自己最有价值的部分。

我写这些，并不是为了否定管理，也不是为了强调某个岗位天然高于另一个岗位。一个组织要运行，销售、行政、运营、支持体系，当然都不可或缺。没有这些角色，组织也不可能稳定。

但我一直想坚持的一点是：这些角色的重要，不在于它们可以取代一线，而在于它们能不能真正成就一线。

如果一家软件公司始终记得，谁在真正创造价值，谁在真正面对客户，谁在真正承担结果，那么它的很多组织选择就会变得比较清楚。它会更愿意把空间留给最接近问题的人，也更愿意让支持体系回到支持的位置，而不是不断向前延伸，最后遮住真正做事的人。

这就是我所理解的“程序员中心”。

它不是一句口号，也不是一种情绪，而是一家公司对自己组织方向的根本选择。