点击参与 2020 开发者大调查：https://bss.csdn.net/m/topic/dev_survey2020，有效信息填写者均能在第一时间获得包含专家解读和丰富干货调查报告的电子版，还有幸运大奖等你来拿。

【编者按】有个很有意思的话题，拿高薪的工程师得做出什么样的成绩才能对得起他们的薪水？一般来说，大部分公司都会选择增加他们的工作量或者工作难度，因为他们的薪水比别人高很多。但是，”硅谷公司“不这样做……

原文标题：What Silicon Valley "Gets" about Software Engineers thatTraditional Companies Do Not

原文链接：https://blog.pragmaticengineer.com/what-silicon-valley-gets-right-on-software-engineers/

作者 | Gergely Orosz，已获作者翻译授权

译者 | 弯月  责编 | 张文

头图 | CSDN 下载自视觉中国

出品 | CSDN（ID：CSDNnews）

以下为译文：

我曾在多家公司工作，既有传统的咨询公司，也有投资银行，还有飞速崛起的科技公司。我也曾与很多软件工程师交谈过，他们之中有人在创业公司工作，也有人从事银行、汽车和高科技，而更多的则是传统公司。这些公司有很多都在硅谷，但也有总部坐落在硅谷之外的公司。

我发现，硅谷公司总是能“获取”一些传统公司既不能理解也无法在实践中实现的价值——尤其是在欧洲。有一些实践经验能够促进公司的创新，帮助工程师得到更好的专业成长，或者说让工程师发挥更大的价值。硅谷公司可以（也愿意）支付更高的薪水，同时也能够从同一个人身上获得更多价值。

在本文中，我通过“硅谷公司”来代指那些能够从每一位工程师身上获取更大价值的现代公司，且这些公司的总部坐落在硅谷（尽管有很多新起之秀并非从硅谷起家）。这类公司的每位工程师的产出能够与 Facebook 或 Google 一较高下。他们使用的方法都很类似，而且能够从其他硅谷公司吸引到人才。

这些公司之所以技高一筹，主要体现在以下几个方面：

 

软件工程师的自主性

 

在传统的公司中，开发人员只需要等着上级给指派工作，大多都是 JIRA 上的任务票。这些任务票由产品经理或项目经理审核，任务票上记载了工作的关键细节。而开发人员只需要按照任务票完成工作。除非任务票中有一些细节需要被澄清，否则就不需要提问。

然而，在硅谷公司中，情况就会有所不同。公司内有很多项目，还有很多程序经理和工程经理。但大多数时候，工程师需要靠自己弄清楚如何完成工作，包括一些重大决策，而且会得到公司的鼓励！在有些情况下，项目的负责人由工程师担任，这样可以方便分解工作。而有些情况下，则由工程经理或高级工程师来承担这些工作。无论采用何种方式，公司都希望鼓励工程师着眼全局，打破固步自封，解决所有他们发现的问题。

工程师的积极主动性是硅谷公司的成功。在这些公司中，经常能看到有些服务和功能是在工程师的建议下构建的，或者在团队成员的倡导下，多个团队共同合作投入专门的时间来解决技术负债。而等着经理来告诉工程师该做什么，或者将他们的工作分解成小块，或事无巨细地管理团队，反而不正常。所有人都是自我管理。

在传统公司，开发人员只需要完成分配给自己的工作。而在硅谷公司，开发人员需要主动解决业务上的问题。这是一个巨大的差别，会影响到工程师每一天的工作。

在传统公司，开发人员只需要完成上司分配的任务，这种人员管理的方式最终都会形成等级制度。我曾与某家银行的职员交谈，他们公司的项目管理有 6 个等级。而开发人员处于最底端的两个级别。所有的决策都必须来自第三层以上。真正干活的人基本上没有任何话语权。不用我多说你就能猜到，这家公司一直被一个问题所困扰：如何让软件工程师好好干活？

图：等级制度。一些传统公司仍然采用了这种形式

与这类公司相比，有些公司则非常清楚工程师有能力解决问题，他们能够比其他任何人更好地解决实际问题。领导都明白争取利益最大化的方式，就是告诉工程师所有的业务背景，给他们执行的空间。

图：向下传达业务目标，并赋予工程师自主权，让他们来做决定，是组织快速前进的动力

 

有思想，有能力的工程师

 

传统公司往往认为，工程师应该将 8 个小时的工作时间全部花在编程上。任何时候，只要工程师没有坐在电脑前面写代码，就是在浪费时间。而且他们不惜高额成本来证明一点。我曾听见有人这样说：

软件工程师的工资比很多职位都要高。我们需要相应的回报。我们不能让他们闲着。

硅谷公司则认为软件工程师是组织中最适合解决问题的人群。招聘工程师不仅是为了技术，还有沟通与解决问题的能力。他们的看法是：

软件工程师是我们公司中薪水最高的人群。这是因为他们编写代码和解决问题的能力能够带来最大的价值。我们希望他们多多接触业务，这样在完成“常规”工作之余，他们还能发现更多重大商机。

在实际工作中，一位有动力的工程师创造的价值是一位听命行事的“工厂工人”的数倍。最差的结果也不过是，在规范清晰正确的情况下，两位工程师都拿出同样的产出。然而，勇于解决问题的工程师在着手工作之前，往往会停下来认真思考，寻找更有影响力的机会。当我问硅谷公司的几位工程师，是否可以做X之后，过了一段时间他们给我的答复是：

• “我做了一点调查，我们确实可以做 X，但是缩小这个功能的范围也不会对业务有任何影响，我们无需做任何代码变更就可以推出这个功能，只需要修改几个配置文件。”

• “对于我们是否可以推出这个项目，其实我有点担心，我觉得我们应该暂时放一放。我调查了一下我们的竞争对手，其中有一家推出了类似的功能，但在被监管机构调查后，又撤销了这个功能。你有没有问公司的法务团队，我们是否可以推出这样的功能？”

• “我看了一下积压的功能列表，项目 Y 与之非常相似。如果我们可以将项目 X 和项目 Y 结合到一起，那么就可以同时发布两个产品，而且还无需额外的开销。”

•  “我们可以在旧的基础设施之上构建这个项目，但是等到一个月后，我们的新基础设施搭建完毕，我们还需要再进行移植。这个项目可以推迟一个月吗？等到新的基础设施准备好之后再动手，就可以避免双倍的工作了。如果业务上没有特殊的需求，要我们在一个月之内推出这个功能，我真心建议再等一等。”

与遵从指示相比，鼓励工程师解决问题的环境带来的价值更高，而且能够做出更好的决策。

 

内部数据、代码与文档的透明度

 

硅谷公司非常重视透明度。尽管也有一些例外，比如苹果或 Palantir，他们给工程师的信息太少了。我发现大多数硅谷公司都愿意分享他们的信息。他们在通用数据保护条例（GDPR）、个人身份信息（PII）以及其他规定的范围内尽可能地分享信息。

员工（不仅是工程师）都有随时访问业务指标与数据资源的权限，他们可以编写自己的查询，并生成自定义的报表。在 Skyscanner，员工每天都会收到有关每日收入明细的汇总邮件。而在 Uber，员工也会收到有关类似指标的周报。

随着各个公司的发展与上市，这些信息会被整合。但是，工程师仍然可以访问公司的业务数据，帮助他们做决策。而在传统的公司，基本不会出现这样的情况。工程师拿到的是规格说明，只有上层才知道决策后面的原因——至少，公司的宗旨就是这样。

 

公开业务与业务指标

 

硅谷公司希望每个团队成员都了解他们的工作将会影响到哪些业务，以及会造成怎样的影响。团队的目标只是推出某个功能的情况非常罕见，比如推出功能 1 可以降低 2%的客户流失率，或者推出项目 X 预计每年可以增加一千万的收入。

硅谷公司鼓励工程师多接触其他业务人员，与工程师之外的人员建立关系。在实践中，很多高级工程师都会与产品经理结伴参加客户研讨大会。但是，我也见过新来的工程师很快就直接与业务利益相关者打成一片。

相反，在传统公司里，开发人员基本上不可能接触其他业务人员。但是，他们可不会表现出来，他们会说：“我们不希望打扰工程师”。我也曾听说，有一位工程经理希望团队成员参加产品发表，却被产品经理拒绝。他们的借口往往是：“我们希望他们好好工作，不希望他们被打扰。”

如果传统公司里的某位工程师与团队以外的人员来往，就会被人说：“不够专心”，“浪费时间”，或者“不务正业”。这类“不正常”的行为常常会给他们的业绩评价带来负面影响。

听起来非常荒谬，有些公司手握一流的解决问题高手，却强制把他们塞进了小格子里，然后说“你只需要写代码”，但是现实就是这样。同时，试图通过代码行数来衡量工程师生产力，或者抱怨为什么工程师不关心产品，也是同一类公司。

 

工程师之间的三角沟通

 

如果你是一位工程师，并且你想问另一个团队一个问题，则可以看看传统公司与硅谷公司之间的差异。

传统公司鼓励等级式沟通。这不仅可以“保护”工程师，而且因为处于这些职位的经理更希望充当信息枢纽，他们不愿放弃这部分的管控。如果你想问另一个团队一个问题，则需要：

图：“传统”/等级制度组织中的沟通

硅谷公司鼓励工程师之间直接进行沟通，不经过中间人。这种沟通方式更快。即便其他团队的工程师帮不上忙，也可以回到“传统”模式，找经理帮忙促进讨论：

图：更有效的沟通

 

努力改善开发人员的工作体验

 

2020 年是糟糕的一年。不是指写代码方面，写代码很容易！而是因为其他相关的工作：设置依赖性、部署到生产或测试环境、CI/CD、监视与警报。如果你在一个由多人组成的团队之中，那么可能没什么问题。然而，你迟早都会遇到这些麻烦。

随着公司的发展，开发人员的体验会越变越糟。刚开始的时候，都是一些小问题：构建时间变得迟缓，依赖性增加，或者需要修改跨多个服务的代码。慢慢地，团队需要搞清楚各自负责的服务；一些迁移规模虽小，但因为涉及多个团队，而出现失败；乃至最终需要重新定义整个工程架构。

框架和库的变化速度非常快，而且很多工具很难跟上步伐。对于各个公司来说，如果不希望开发人员的体验变糟，就必须鼓励工程师侧重于解决问题，建立各种基础设置、平台和 SRE 团队。

一些的软件工程师的工作目标只是为了让其他软件工程师能更快地工作，听起来似乎有违常理，但很多时候并非如此。帮助这些公司快速发展，能够获得巨大的回报，而且开发人员也更加快乐。

 

自主性与高薪之间的杠杆效应

 

硅谷公司愿意向工程师支付高薪，为的是获得更高的杠杆率，因为这些工程师带来的价值超过了他们的薪水。这种杠杆效应既可以来自规模，也可以来自业务发展。减少在不必要的沟通上浪费的时间，利用工具等都可以为这种杠杆带来价值。给工程师足够的自主权，可以为业务发展做贡献，也可以保持高杠杆率。

如今 Google、Facebook 和其他公司支付的高薪都是规模的杠杆效应。这些公司的工程师构建的功能拥有数百万的用户。这种杠杆效应和附加的价值本身就是回报。

图：自主性越高，杠杆率越高，创造的价值越高，薪水就越高（同时公司还能攫取巨额利润）

硅谷公司就是利用软件工程师来发展业务。FogCreek 的软件工程师正是通过这种方式实现了百万美元的广告分类。Facebook 的工程师和设计师也是通过这种方式构建了点赞按钮。这个小小的按钮带来的是几十亿的商机：Facebbok 通过按钮定位广告，并在 Facebook 之外追踪用户。

如果上面这些人在传统环境中工作，那么他们的想法永远也不会有机会实现。硅谷的创业公司鼓励工程师提出商机，然后再实现。提出想法的人和公司业务都可以从中获益。

利用工程师建立杠杆效应的公司根本不发愁支付市场最高昂的薪资，甚至超过最高水平。Basecamp 就是一个很好的例子，虽然不是科技巨头，但他们也很好地利用了工程师，因此他们也能支付软件市场的高昂薪资，同时还能保持盈利。

 

整体最大的区别

不同类型的公司在处理与工程师之间的关系方面有很多差异。最大的区别就在于，硅谷公司认为工程师能够创造价值，拥有解决问题的能力；而传统公司则将他们当成工厂的工人。

思想上的这种分歧导致，思想比较前卫的公司不仅能够支付更高的薪水，而且还能给予工程师更多自主权。而工厂工人的价值是预先定义好的，你可以做出预算。另一方面，如果利用得当，富有创造性、能够解决问题的工程师可以带来10 倍的价值。因此，向他们支付更高的薪水，给他们更多自由，自然也很合理，因为这是你激励他们贡献更多业务价值的手段。

在硅谷公司之类的环境中工作过的人，很难回到传统的工作场所，在那里，每个人的职责都有明确的定义，每次你离开自己的小格子，就会有人皱眉头。

作为软件工程师，在负责解决问题的环境中工作更加令人心神愉悦，而不是作为一名工厂工人。如今的你身在哪边？

原文：https://blog.pragmaticengineer.com/what-silicon-valley-gets-right-on-software-engineers/

本文为 CSDN 翻译，转载请注明来源出处。

参与开发者大调查猛戳这里：https://bss.csdn.net/m/topic/dev_survey2020

查看评论