创业公司留不住人？因为你不懂软件工程师
神译局是36氪旗下编译团队，关注科技、商业、职场、生活等领域，重点介绍国外的新技术、新观点、新风向。
编者按：同样一个人，到了类硅谷的科技公司之后为什么表现就跟着原先的传统公司大相径庭？传统公司不同类型的公司在处理与工程师的关系方面的确存在很多方面的差异。不过，最大的是这个。“类硅谷公司”会把工程师看作是价值创造者，看作是创造性的问题解决者。而传统公司只是把他们看作是工厂的工人。曾经在多家公司待过的Gergely Orosz总结了个人的感受。结合最近职场发生的一些热点事件，看完本文之后，你也许也会有更深的感受。原文发表在pragmaticengineer上，标题是：What Silicon Valley "Gets" about Software Engineers that Traditional Companies Do Not。
划重点：
类硅谷公司的软件工程师有更高的自主权
是好奇的问题解决者，而非无意识的资源
他们拥有更加开放的环境，而不是被提防
他们受到鼓励积极地跟其他业务部门互动
工程师跨部门直接沟通比逐级上报更高效
类硅谷公司会为开发营造更加舒心的环境
更高的杠杆意味着更高的自主性以及薪酬
我曾有过之多家科技公司工作的经历：从“传统”商店和咨询公司，到投资银行，再到高成长的科技公司。我还曾经跟在初创公司、银行、汽车公司、大型科技公司以及更“传统”的公司工作过的软件工程师交流过。丰富的经历让我对硅谷公司以及总部位于该地区以外的公司有了一份健康的样本。
我已经注意到，有些传统竞争对手（尤其是欧洲）总是无法理解或者在实践中没法实施的东西硅谷公司一直都很“懂”。这些做法对公司来说可以加快创新速度，对工程师来说可以加快个人成长，以及更好的“利用率”（这不知道是好还是坏）。反过来，硅谷的公司就可以支付更高的工资（的确如此），并且从同一个人身上获得更多的价值。
在本文中，我会用“类似硅谷的公司”来指代能够很好发挥软件工程人员影响力的现代公司，而这些公司传统上总部一般都在硅谷——虽然很多新公司不再如此。这是每一位工程师的工作产出可与Facebook或Google之类的公司相媲美的公司。他们也采用了类似的做法，往往可以吸引到其他“类硅谷”公司的人才。
这些公司比其他许多公司更“懂得”哪些事情呢？以下就是关键。
1.软件工程师的自主权
在“传统”公司，开发人员的工作事项一般是分配来的——一般是JIRA工单的形式。这些工单由产品（或项目）经理审核，而且列出来要完成工作最关键的细节。对开发者的预期就是不多不少就做这些。整个过程没有什么可质疑的，除非要澄清工单的细节。
加盟“类硅谷公司”的话，这些几乎看不到。是，他们也有项目，有项目经理和工程经理。但在大多数情况下，他们对工程师的预期（以及鼓励）是弄清楚工作的“how”，包括做出更大的决定。在有的地方，每个项目都会由一名工程师领导，以便于的工作拆分。在其他地方，工程经理或高级工程师可以执行此项工作。不管最后是怎么完成的，他们都会激励所有工程师着眼全局，释放自己，并解决他们看到的任何问题。
“类硅谷”公司赞美工程师的主动性。你往往会看到工程师对服务和功能提出建议，或者让团队腾出专门的时间来偿还技术债务。对于经理来说，告诉工程师具体要干什么，把他们的工作分解成小块，或者对其进行微管理是很罕见的。大家都是自我管理。
传统公司对开发人员的期望是完成分配的工作。在类硅谷公司里，对他们的预期是解决业务存在的问题。这是一个巨大的差异，会影响任何一位工程师的日常工作。
在传统公司中，开发人员做要求去做的事情往往是自上而下层层传达的。我曾经跟一个字银行工作的人聊过。他们那里的项目管理有6个层级。而开发人员排在最下面的两级。决策只能从第三级开始进行。也就是说，从事这项工作的人基本都没有发言权——这是设计使然。这家银行一直努力解决软件部门不奏效的问题，原因还需要我说吗？
世界的等级视图。一些传统公司仍然是这种工作机制，最下层的开发者没有决策权
跟那些公认的自己的工程师比其他任何人都能够更好地在一线解决实际问题的地方相比一下。那里的领导知道，把所有的相关业务背景分享出来，并赋予工程师执行的空间，这符合企业的最大利益。
传达背景信息并给予自治权来进行决策是组织高效前进的动力。
2.好奇的问题解决者，而非无意识的资源
传统公司往往把工程师看作是8小时的编码机器。任何不在计算机前面敲编码的时间往往会被看成是浪费。他们很高的代价来证明了这一点。我听说有人是这么推理的：
跟其他职能部门相比，软件工程师的薪水更高。所以相应地我们得好好利用这帮人。我们不能让他们闲着。
“类硅谷公司”会把软件工程师视为最适合解决组织所遇到的问题的人。他们雇的不仅是技术技能，还包括沟通和解决问题的能力。他们的想法有点像这样：
软件工程师是我们公司收入最高的人之一。这是因为他们可以通过编码和解决问题带来最大的影响力。我们希望他们熟悉业务，这样，当他们进行自己的“常规”工作时，还可以为业务找到更有意义的机会。
在实践中，有干劲的工程师可以轻松地让说什么就做什么的“工厂工人”的影响力倍增。在最坏的情况下，当工作规范清晰正确时，大家的输出相同。但是，受到鼓励去解决问题的工程师通常会停下来思考，然后再着手工作，一边寻找机会去发挥更大的影响。在被问到是不是可以执行X之后，我在“类硅谷”公司看到工程师是这么对话的：
“我做了一些调查，虽然我们是可以做X，但是如果可以缩小这项功能范围而不会对业务产生影响的话，那我们就可以在不进行任何代码变更的情况下发布这项功能，只需要改变一下配置文件就行了。”
“我担心我们这个项目能不能交付，我觉得应该暂停这个项目。我看了一下竞争对手的工作，其中一个竞争对手已经推出了类似功能，但在监管机构对其进行调查之后又撤销掉了。我们是不是已经跟法律团队核实过可以做？”
“我看了下我们积压的项目，Y项目跟现在这个很相似。如果把X项目和Y项目结合在一起的话，我们可以用很少的开销交付两个东西。”
“我们要么可以在旧的基础设施上开发这个项目，但是之后就得迁移到一个月内建成的新的基础设施上面；或者我们可以把项目推迟一个月，直到新的基础设施准备就绪，以避免重复工作。如果没有充分的商业理由必须在一个月内推出的话，我真心建议选择后面这个方案。”
在鼓励解决问题，注重结果而不是遵循指示的环境下，可以做出更好的决策。
3.内部数据，代码以及文档的透明度
硅谷公司的透明度很高。虽然也有例外——苹果或Palantir可能会非常谨慎地向工程师提供尽可能少的信息——但我观察到的大多数“类硅谷公司”都会尽可能地开放。他们会用符合GDPR、PII以及其他需遵循的监管要求的方式进行这种操作。
员工（不仅是工程师）经常可以访问到实时的业务指标和数据源，从而可以自己写查询并创建自定义的报告。在Skyscanner这里，我们每天都会收到有关当天收入明细的每日摘要电子邮件。在Uber，每周也都会发布一份有着类似指标的每周增长通讯邮件。
随着公司的发展乃至于最后上市，这些信息就会合并起来。尽管如此，工程师仍然可以访问自身组织的业务数据，从而帮助指导做出决定。
在传统公司里面，这些做法很多都是不存在的。工程师会拿到规范，更高级别的工程师会知道为什么要做出这样的决定——至少他们的想法是这样的。
4.接触业务和业务指标
在硅谷公司，他们的预期是每一位团队成员都了解自己的工作会对业务的哪一部分产生影响以及是如何影响的。团队的目标很少只是发布功能：通过发布功能1来减少2％的客户流失，或者通过发布ProjectX来让收入每年增加1000万美元。
硅谷工程师会受到鼓励，去跟企业的其他部门互动，去跟其他工程师以外的人建立关系。实际上，更多的高级工程师一般会这么做：从跟产品经理进行1：1对话到参加客户研究会议。但是我已经看到新入职的工程师直接就跟业务方面的利益相关者合作，而没有任何人使眼色。
相比之下，传统公司往往会让开发人员没有办法跟其他的业务部门互动。但是他们不会明说。他们会说“我们要保护我们的工程师，避免他们被干扰”。但是我曾听说过有位工程经理想要邀请自己的团队成员参加产品演示，而产品经理却拒绝了这个想法的事情。“我们需要他们工作，他们分心的代价我们负担不起。”是一个常见的借口。
当传统公司的工程师想着团队之外建立关系时，他们经常会被讲他们“精力不够集中”，是“浪费时间”或者从事“与他们无关的事情”。这种“异常”活动往往会在绩效评估的时候被打负分。
在我看来，公司给那些最好的问题解决者画地为牢，强迫他们“敲好你的代码”就行的说法实在是太疯狂了，但是这种情况正在发生。那些试图用跟代码行相关的指标来衡量工程效率的公司，就会怀疑自己的工程师为什么不以产品为中心或者不具备产品意识。
5.工程师对工程师的沟通与逐级上报
如果你是一名工程师，并且对另一个团队的工作方式有疑问时，你在传统公司和在“类硅谷公司”的所采取的做法会有所不同。
传统公司会鼓励逐级上报，层层沟通。这既是为了“屏蔽”工程师，又是因为这些地方的经理更喜欢自己成为信息中心，而不是放弃这部分的控制。对另一个团队的疑问或者请求往往会是这样的遭遇：
在“传统”/等级组织里面的沟通
“类硅谷公司”鼓励工程师之间加强沟通，不要中间人。在所有情况下，这种沟通方式都要更快。而且在其他团队的工程师无法提供帮助的情况下，这个过程还可以回退到那种经理的“传统”模式，靠中间人来帮助促进讨论：
沟通要有效得多
6.投资于一个不那么令人沮丧的开发者体验
2020年做开发可能会令人沮丧。但不是因为写代码——写代码并不难！——麻烦的是周边的东西。要设置好依赖。要部署到生产或测试环境。要做CI / CD（持续集成/交付）。要实现监视和警报。当你的团队只有几个人的时候，这些到不是什么大问题。尽管如此，但问题仍会时不时地出现。
不过，随着公司的发展，开发人员的体验会变得越来越令人沮丧。这会从比较小的事情开始，比方说构建的时间变慢了，依赖项不断增加了，或者需要进行跨服务的变更。然后还有哪支团队负责哪项服务的问题，小小的迁移影响到了很多支团队，乃至于最后要对整个工程重新定义架构。
框架和工具的变化很快，工具是很少能跟上的。关心工程师的公司会专注于解决问题，会迅速建立起各种基础设施、平台以及减少开发者体验流失的SRE团队。
雇用只专注于让其他的软件工程师能提高工作效率的软件工程师？这听起来似乎有违直觉，但对很多地方来说不是的。帮助这些公司更快地前进，并让开发者情绪高涨，这可以收到丰厚回报。
7.更高的杠杆-->更高的{自主性，薪酬}
任何想要靠高新争取到工程师的类硅谷的公司都需要创造出高杠杆，也就是这些工程师带来的价值必须超过付给他们的薪水。这种杠杆作用既可以表现在规模上，也可以表现在企业的发展壮大上。减少把时间浪费在不必要的沟通等事情上，多利用工具，这些都可以增加这种杠杆作用。要赋予工程师足够的自主权，让他们为企业做出贡献，这就是你可以保持这种优势的办法。
如今，谷歌，Facebook等知名公司都在支付高薪，这属于规模杠杆。这些公司的工程师往往会开发出数百万客户使用的功能。这种杠杆作用和增值本身就是回报。
更高的自主权-->更高的杠杆率-->创造出更高的价值-->更高的报酬（与此同时所有公司仍然能够盈利）
类硅谷的创业公司所做的就是利用软件工程师来发展业务。Fog Creek软件公司的一位软件工程师就为ad classfields实现了一个一百万美元的想法 。Facebook的工程师和设计师开发出了“点赞”，这个小小的按钮影响到了数十亿美元的生意：这让Facebook可以发送（重新）定向广告，并“跟踪” Facebook网站之外的用户。
如果上面提到的任何人是在“传统”的环境下工作的话，他们的想法就会是：想想而已。“类硅谷”的创业公司会激励工程师推进自己的业务点子，并实现出来，而他们会乐此不疲。对于有想法的人和企业本身来说，大家都过得更好了。
能够让工程师人尽其才的公司给他们支付接近或者高于市场最高价格的薪水会毫无问题。Basecamp就是能够很好地利用工程师但不属于“科技”大公司的很好例子。什么意思？意思是说他们可以在全球范围内给出跟旧金山市场一样的基本工资，同时仍能保持盈利。
最大的总体差异在哪里
不同类型的公司在处理与工程师的关系方面的确存在很多方面的差异。不过，最大的是这个。“类硅谷公司”会把工程师看作是价值创造者，看作是创造性的问题解决者。而传统公司只是把他们看作是工厂的工人。
这种思想上的分歧使得有远见的公司愿意给工程师支付更高的薪水，并赋予他们更大的自主权。而作为工厂的工人，其附加价值是非常明确的，是可以做规划的。反过来，如果使用得当的话，一位富有创造力的问题解决者可以给企业带来10倍的价值。给他们更高的报酬，给予他们更多的自由是行得通的，因为只有这样，你才能够激励他们为企业创造出更高的价值。
一旦你在类硅谷的环境下工作过，就还很难再愿意回到“传统”的职场，在那里，人人都扮演着明确的角色，而一旦你从那里出走时，你就会眼前一亮。
作为软件工程师，在被看作解决问题者而不是工厂工人的地方工作才舒服。你现在是在哪里工作呢？
译者：boxi
本文来自翻译, 如若转载请注明出处。