创业公司留不住人？因为你不懂软件工程师( 二 ) 神译局是36氪旗下编译团队

跟那些公认的自己的工程师比其他任何人都能够更好地在一线解决实际问题的地方相比一下。那里的领导知道，把所有的相关业务背景分享出来，并赋予工程师执行的空间，这符合企业的最大利益。

文章图片
传达背景信息并给予自治权来进行决策是组织高效前进的动力。
2.好奇的问题解决者，而非无意识的资源
传统公司往往把工程师看作是8小时的编码机器。任何不在计算机前面敲编码的时间往往会被看成是浪费。他们很高的代价来证明了这一点。我听说有人是这么推理的：
跟其他职能部门相比，软件工程师的薪水更高。所以相应地我们得好好利用这帮人。我们不能让他们闲着。
“类硅谷公司”会把软件工程师视为最适合解决组织所遇到的问题的人。他们雇的不仅是技术技能，还包括沟通和解决问题的能力。他们的想法有点像这样：
软件工程师是我们公司收入最高的人之一。这是因为他们可以通过编码和解决问题带来最大的影响力。我们希望他们熟悉业务，这样，当他们进行自己的“常规”工作时，还可以为业务找到更有意义的机会。
在实践中，有干劲的工程师可以轻松地让说什么就做什么的“工厂工人”的影响力倍增。在最坏的情况下，当工作规范清晰正确时，大家的输出相同。但是，受到鼓励去解决问题的工程师通常会停下来思考，然后再着手工作，一边寻找机会去发挥更大的影响。在被问到是不是可以执行X之后，我在“类硅谷”公司看到工程师是这么对话的：
“我做了一些调查，虽然我们是可以做X ，但是如果可以缩小这项功能范围而不会对业务产生影响的话，那我们就可以在不进行任何代码变更的情况下发布这项功能，只需要改变一下配置文件就行了。 ”
“我担心我们这个项目能不能交付，我觉得应该暂停这个项目。我看了一下竞争对手的工作，其中一个竞争对手已经推出了类似功能，但在监管机构对其进行调查之后又撤销掉了。我们是不是已经跟法律团队核实过可以做？”
“我看了下我们积压的项目， Y项目跟现在这个很相似。如果把X项目和Y项目结合在一起的话，我们可以用很少的开销交付两个东西。 ”
“我们要么可以在旧的基础设施上开发这个项目，但是之后就得迁移到一个月内建成的新的基础设施上面；或者我们可以把项目推迟一个月，直到新的基础设施准备就绪，以避免重复工作。如果没有充分的商业理由必须在一个月内推出的话，我真心建议选择后面这个方案。 ”
在鼓励解决问题，注重结果而不是遵循指示的环境下，可以做出更好的决策。
3.内部数据，代码以及文档的透明度
硅谷公司的透明度很高。虽然也有例外——苹果或Palantir可能会非常谨慎地向工程师提供尽可能少的信息——但我观察到的大多数“类硅谷公司”都会尽可能地开放。他们会用符合GDPR、PII以及其他需遵循的监管要求的方式进行这种操作。
员工（不仅是工程师）经常可以访问到实时的业务指标和数据源，从而可以自己写查询并创建自定义的报告。在Skyscanner这里，我们每天都会收到有关当天收入明细的每日摘要电子邮件。在Uber ，每周也都会发布一份有着类似指标的每周增长通讯邮件。
随着公司的发展乃至于最后上市，这些信息就会合并起来。尽管如此，工程师仍然可以访问自身组织的业务数据，从而帮助指导做出决定。
在传统公司里面，这些做法很多都是不存在的。工程师会拿到规范，更高级别的工程师会知道为什么要做出这样的决定——至少他们的想法是这样的。
4.接触业务和业务指标
在硅谷公司，他们的预期是每一位团队成员都了解自己的工作会对业务的哪一部分产生影响以及是如何影响的。团队的目标很少只是发布功能：通过发布功能1来减少2％的客户流失，或者通过发布ProjectX来让收入每年增加1000万美元。
硅谷工程师会受到鼓励，去跟企业的其他部门互动，去跟其他工程师以外的人建立关系。实际上，更多的高级工程师一般会这么做：从跟产品经理进行1：1对话到参加客户研究会议。但是我已经看到新入职的工程师直接就跟业务方面的利益相关者合作，而没有任何人使眼色。
相比之下，传统公司往往会让开发人员没有办法跟其他的业务部门互动。但是他们不会明说。他们会说“我们要保护我们的工程师，避免他们被干扰” 。但是我曾听说过有位工程经理想要邀请自己的团队成员参加产品演示，而产品经理却拒绝了这个想法的事情。 “我们需要他们工作，他们分心的代价我们负担不起。 ”是一个常见的借口。