为什么硅谷型公司更懂软件工程师？自主权、业务意识与研发效能的差异

我曾在多种类型的科技相关公司工作过：从传统科技公司、咨询公司，到投资银行，再到高速增长的科技公司。我也和许多软件工程师交流过，他们分别来自初创公司、银行、汽车公司、大型科技公司，以及其他更传统的企业。这些公司有的位于硅谷，有的总部则在硅谷之外。

我注意到，硅谷型公司往往真正理解了一些传统公司没有理解，或者即便理解了也无法在实践中落实的事情。它们更懂得如何发挥软件工程师的价值，如何通过工程师自主权、业务理解、透明信息和工程效率提升，持续创造更高的组织杠杆。

这些事情能够加快公司层面的创新速度，推动工程师职业发展，也能提升员工创造价值的能力。反过来，硅谷型公司也因此能够支付更高的薪酬，并从同一位员工身上获得更大的价值。

在本文中，我会用“硅谷型公司”来指代这样一类现代公司：它们能够通过每一次软件工程师招聘，创造很高的杠杆效应。这类公司传统上往往总部位于硅谷，但如今很多新兴公司已经不再起源于那里。它们通常具备类似头部互联网公司的单位人效，采用相似的工程方法论，也往往能够吸引来自其他硅谷型公司的工程人才。

下面，是这些公司相比许多传统公司做得更好的几个关键点。

1. 软件工程师拥有更高自主权

在传统公司里，开发人员通常会被分配具体工作项，最常见的是工单系统中的任务。这些工单通常已经由产品经理或项目经理整理过，里面包含完成工作所需的大部分关键信息。开发人员也被期待按这种方式工作。除非需要澄清某个细节，否则他们很少需要提出额外问题。

加入一家硅谷型公司后，你几乎不会看到完全相同的工作方式。

那里也有项目，也有产品经理、项目经理和工程经理。但在大多数情况下，工程师需要，也会被鼓励，自己弄清楚“具体该怎么做”，其中包括做出一些重要决策。

在一些公司里，每个项目都会有一位工程师负责牵头，由他或她来拆解工作。在另一些公司里，工程经理或高级工程师也可能承担这部分职责。无论具体形式如何，所有工程师都会被鼓励关注全局、主动排除障碍，并解决自己遇到的问题。

在硅谷型公司中，工程师的主动性非常受重视。你经常会看到工程师提出的新服务或新功能最终被开发出来，也会看到团队专门投入时间，偿还由团队成员倡议的技术债务。

管理者很少会详细告诉工程师每一步具体该做什么，也很少会把所有工作拆成小块，再进行微观管理。工程师通常需要自我管理。

传统公司对开发人员的期待，是完成分配给他们的任务。而硅谷型公司对工程师的期待，是解决业务真正面临的问题。

这两者之间的差异非常大，并且会影响每一位工程师的日常工作。

在传统公司里，“开发人员只需要服从指令”的理念，往往会催生层级森严的组织结构。我曾与一家海外银行的员工交流过，那家银行的软件项目管理层级多达六层，而开发人员位于最底下两层。真正的决策权要到第三层以上才存在。

换句话说，实际执行工作的人几乎没有发言权，而且这是组织有意设计出来的。毫不意外的是，这家银行的软件部门当时正面临严重的运作问题。

相比之下，在硅谷型公司里，工程师通常被认为是最了解实际问题、也最有能力解决问题的人。领导者清楚地知道：向工程师充分分享相关业务背景，并给予他们足够的执行空间，才最符合公司的长期利益。

2. 工程师是问题解决者，而不是机械执行的资源

传统公司常常认为，工程师每周应该把绝大多数时间用于写代码。任何不坐在电脑前写代码的时间，往往都会被视为浪费。

这种想法通常会用“成本”来解释。我曾听人这样说过：

“软件工程师的薪酬比很多其他职能都高。我们必须合理利用他们的时间，不能让他们闲着。”

硅谷型公司则有完全不同的理解：软件工程师是解决公司问题的最佳人选之一。招聘工程师时，它们不仅看重技术能力，也看重沟通能力和解决问题的能力。

它们的思路更接近这样：

“软件工程师是公司中薪酬最高的一类员工之一，这是因为他们能够通过写代码和解决问题，为公司创造最大的影响。我们希望让他们接触业务，这样他们在完成日常工作的同时，也能发现对公司更有价值的机会。”

事实上，积极主动的工程师所能产生的影响，常常是机械执行者的数倍。后者只会完成别人告诉他们要做的事。

即使在最简单的情况下，当工作规范已经非常清楚时，两者的产出可能也只是相同而已。但那些被鼓励解决问题的工程师，往往会在开始动手前先停下来思考，从而发现更有影响力的路径。

我在硅谷型公司里就经历过很多类似对话。当我问工程师是否可以做某项工作时，他们给出的回答常常不是简单的“可以”或“不可以”，而是类似下面这样：

“我做了一些调查。我们当然可以做 X，但如果能稍微缩小这个功能的范围，对业务影响其实不会有太大差别。而且这样我们就不需要改任何代码，只要调整几个配置文件，就能发布这个功能。”

“我担心这个项目能否顺利上线。我建议先暂停一下。我查了竞争对手的情况，其中一家曾经发布过类似功能，但后来在受到监管调查后撤回了。我们是否已经和法务团队确认过，这个功能仍然可以发布？”

“我看了一下待办事项，发现项目 Y 和项目 X 非常相似。如果我们把两个项目合并，就可以用很小的额外成本同时交付两个项目。”

“我们现在可以基于现有基础设施构建这个项目，但之后还需要迁移到一个月后才会完成的新基础设施上。为了避免重复劳动，能不能把项目推迟一个月，等新基础设施准备好再做？如果没有必须在一个月内上线的强商业理由，我强烈建议这样安排。”

在鼓励解决问题、关注结果，而不是单纯遵循指令的环境中，团队通常会做出更好的决策。

3. 内部数据、代码和文档更加透明

透明度在硅谷型公司中非常重要。虽然也有少数例外，例如某些高度保密的海外公司只向工程师提供“完成工作所需的信息”，但我观察到，大多数硅谷型公司都会尽可能多地分享信息。当然，它们也会遵守隐私合规、个人信息保护以及其他适用于自身业务的法规要求。

员工通常不仅仅是工程师，都可以访问实时业务指标和数据源，从而编写自己的查询，创建自定义报告。

在我曾经工作过的一家公司里，我们每天都会收到包含当日收入明细的汇总邮件。在另一家高速增长的科技公司里，我们每周都会收到一份包含类似指标的增长简报。

随着公司规模变大并走向上市，这些信息会逐渐被整合和规范。尽管如此，工程师通常仍然能够获取公司内部的业务数据，用来辅助判断和决策。

而在传统公司中，这种情况并不常见。工程师往往只能拿到技术规格说明，而高层管理者才会了解决策背后的业务原因，至少理论上是这样。

这种信息不对称，会直接影响工程师的判断质量。你无法期待一个不了解业务背景的人，做出对业务最有价值的技术决策。

4. 工程师能够接触业务和业务指标

在硅谷型公司中，团队成员通常必须了解自己的工作会如何影响业务，以及影响范围有多大。

团队目标很少只是“发布某个功能”。更常见的目标是：通过推出某个功能，将客户流失率降低 2%；或者通过发布某个项目，预计每年新增数千万收入。

硅谷型公司鼓励工程师与业务部门成员互动，并在工程团队之外建立联系。实际上，资深工程师往往会更频繁地这样做：从与产品经理一对一沟通，到参与客户调研，都是常见做法。

我也见过一些刚入职不久的工程师直接与业务利益相关者合作，而大家对此习以为常。

相比之下，传统公司往往会阻碍开发人员与公司其他部门沟通。当然，它们通常不会这样解释，而是会说：“我们希望让工程师免受干扰。”

我听过这样一个故事：一位工程经理想邀请团队成员参加产品演示，却被产品经理拒绝了。对方给出的理由是：“我们需要他们工作，不能让他们分心。”

在传统公司里，如果工程师与团队之外的人建立联系，常常会被认为“不够专注”“浪费时间”，或者“做了不属于自己职责范围的事情”。这种看似“越界”的行为，甚至可能出现在绩效评估中，并被视为负面因素。

在我看来，公司把一些最有能力解决问题的人，强行塞进“只管写代码”的框框里，是一件非常不可思议的事。但现实中，这种情况并不少见。

那些试图用代码行数、提交次数等指标来衡量工程效率的公司，往往又会疑惑：为什么我们的工程师缺乏产品意识？为什么他们没有业务思维？

答案其实很简单：他们从一开始就没有被允许理解业务。

5. 工程师之间直接沟通，而不是层层转达

当你是一名工程师，并且对另一个团队如何做某件事有疑问时，在传统公司和硅谷型公司中，你通常会采取完全不同的沟通路径。

传统公司往往鼓励层级式沟通。一方面，它们声称这样可以“保护”工程师，让他们少受打扰；另一方面，这些公司的管理者也更倾向于成为信息中枢，不愿放弃对信息流的控制权。

在这种组织里，向其他团队提出问题或请求，通常需要通过自己的经理，再到对方经理，最后才传递给真正能回答问题的人。信息在层层转发中被稀释、延迟，甚至被误解。

硅谷型公司则更鼓励工程师之间直接沟通，尽量减少中间环节。这在几乎所有情况下都更快。

如果对方团队的工程师无法提供帮助，再回到传统模式，请经理协助组织讨论也不迟。

直接沟通不意味着混乱。相反，它意味着把问题交给最了解上下文、最有能力快速解决的人。对于跨团队协作来说，这一点尤其重要。

在这类跨团队协作场景中，工具本身不应该成为新的信息瓶颈。对于需要同时推进任务、文档、会议、目标、日历和审批的组织，Worktile 这类通用项目协作系统可以帮助不同职能团队在同一个协作空间里同步信息、沉淀决策，减少层层转达带来的沟通损耗。

6. 投资于开发者体验，减少研发摩擦

软件开发中真正让人沮丧的，往往不是写代码本身。写代码很多时候反而是最简单的部分。

真正消耗开发者精力的，是那些围绕代码周边的复杂事情：配置依赖、部署到测试环境或生产环境、维护持续集成和持续交付流程、处理监控与告警、排查构建问题、协调跨服务变更等等。

如果你的团队只有几个人，这些问题可能还不算严重。即便如此，它们也会时不时出现。

但随着公司规模扩大，开发者体验往往会越来越糟。

一开始可能只是构建时间变长、依赖变多，或者需要跨服务修改代码。后来问题会逐步扩大：你需要弄清楚哪个团队负责哪个服务，小型迁移会因为影响多个团队而变得复杂，最终甚至可能需要重新定义整个工程架构。

框架和工具更新换代很快，而内部工具往往跟不上变化。那些真正重视工程师能否专注解决问题的公司，会迅速建立基础设施团队、平台团队和可靠性团队，用来降低开发者的摩擦成本。

招聘专门提升其他软件工程师工作效率的软件工程师，乍一看似乎有些反直觉。但在很多地方，这恰恰是非常合理的投资。

这种做法能带来丰厚回报：它帮助公司加快发展速度，也让开发人员更满意、更愿意留下来。

对于无法自研完整内部平台的团队来说，也可以借助 PingCode 这类智能化研发管理工具，把团队目标、客户反馈、需求评审、开发、测试、发布和 Wiki 知识沉淀串联起来，并打通研发过程中使用的其他工具，让研发数据顺畅流转，从而减少流程摩擦，提升研发效能。

7. 更高杠杆带来更高自主权，也带来更高薪酬

任何希望在工程师薪酬上具备竞争力的公司，都需要创造足够高的杠杆效应，让工程师创造的价值超过其薪资成本。

这种杠杆既可以体现在规模扩张上，也可以体现在业务增长上。减少不必要的沟通、减少低效工具使用、降低流程摩擦，都能提升这种杠杆效应。

给予工程师足够自主权，让他们为业务做出超出预期的贡献，是保持高杠杆效应的关键。

一些老牌大型科技公司之所以能够支付高薪，很大程度上是因为规模效应。它们的工程师开发的功能，可能会被数百万甚至数十亿用户使用。这样的规模效应和增值空间，足以覆盖高昂的人力成本。

硅谷型初创公司则会充分利用软件工程师的能力来推动业务增长。

历史上，许多高价值的产品创意都来自工程师或设计师的主动提议，而不是从上层规划中分配下来。某些看似很小的功能，最终可能成为创造巨大商业价值的基础。

如果这些人处在传统环境中，他们的想法很可能永远只是想法。因为他们没有渠道提出，也没有自由去验证。

硅谷型创业公司会激励工程师提出商业想法，并参与将这些想法付诸实践。这对所有人都有益：提出想法的人能够发挥创造力，公司也能捕捉到新的增长机会。

善于利用工程师创造力的公司，支付接近甚至高于市场最高水平的薪酬并不是问题。也有一些并非大型科技公司的海外软件公司，能够很好地利用工程师资源，因此既能支付很高的薪酬，又能保持盈利。

技术是利润中心，而不是成本中心

理解硅谷型公司与传统公司差异的另一个角度，是看它们如何看待技术。

硅谷型公司通常把技术视为利润中心，而不是成本中心。

如果一家公司认为技术只是成本，那么它自然会试图压缩工程投入、控制人力成本、衡量代码产出，并把工程师当作执行资源。

但如果一家公司认为技术是利润中心，它就会思考：如何让工程师创造更大价值？如何让技术直接推动业务增长？如何通过平台、工具、流程和组织设计，让技术人员产生更高杠杆？

这两种思维方式，会最终塑造出完全不同的组织。

前者倾向于层级、控制和任务分配。后者则倾向于透明、自主和问题解决。

总结：软件工程师是价值创造者，而不是流水线工人

不同类型公司对待工程师的方式存在很多差异。其中最核心的一点是：

硅谷型公司把工程师视为价值创造者和富有创造力的问题解决者；传统公司则更容易把工程师视为工厂工人。

这种思维方式的差异，使得更具前瞻性的公司既能为工程师提供更高薪酬，也能给予他们更大自主权。

工厂工人的附加值相对明确，可以规划，也可以被严格控制。但富有创造力的问题解决者，如果被合理利用，可能创造十倍于机械执行者的价值。

因此，给予他们更高薪酬和更大自由度是合理的，因为这能让他们为企业创造更大的价值。

一旦你体验过硅谷型工作环境，就很难再回到那种传统职场：每个人都被限定在非常狭窄的角色中，一旦你试图越出边界，人们就会感到惊讶。

对于软件工程师来说，真正令人愉悦的工作环境，是一个允许你解决问题的地方，而不是一个把你放在流水线上的地方。

你今天所处的环境，更接近哪一种？