下面的内容是我在作为一名程序员入职之前阅读的由Gergely Orosz写的The Software Engineer’s Guidebook。我将将阅读时得到的重要的信息总结成中文以供大家分享。
在本书之前的章节中，我们讨论了“技术负责人”更多是一种角色，而不是一个明确的头衔或职业级别。那么，在没有技术负责人职业级别的公司里，高级工程师之后是什么职位呢？高级工程师之上的第一个级别通常被称为“资深工程师”（Staff Engineer）或“首席工程师”（Principal Engineer）。
在谷歌，高级工程师（L5）之后是资深工程师（L6），接着是高级资深工程师（L7）、首席工程师（L8）、杰出工程师（L9）以及研究员（L10）。许多大型科技公司采用了类似的路径：高级工程师 → 资深工程师 → 首席工程师 → 杰出工程师。Uber和Databricks的职业发展路径与此类似。Netflix和Dropbox也有类似的级别，只是这些公司在本书出版时并未设立“杰出工程师”级别。
然而，科技公司对高级工程师之上的头衔有着略微不同的看法。例如，微软、亚马逊和Booking.com并没有“资深工程师”这个概念；高级工程师之后的下一个职业级别是“首席工程师”。还有一些公司使用其他头衔，比如“架构师”（Oracle）、“首席技术人员”（eBay）或“首席顾问”（ThoughtWorks），作为高级工程师之后的级别。
为什么各家公司对头衔的定义差异如此之大？这是因为各公司的期望不同。值得研究一家公司的头衔体系并问以下问题：
一家公司的完整职业阶梯是什么？这可以更好地了解某些资深工程师及以上头衔的资历水平。一个很好的资源是网站Levels.fyi，它可以帮助你了解各家公司在高级工程师之上的职业级别。不过需要注意的是，比较两家公司职位的职责范围比网站展示的要难得多，因为细节才是关键所在。
某个职位的工程和业务影响是什么？一个资深工程师负责的系统如果每年产生100万美元的收入且仅被少数客户使用，与另一个资深工程师负责的系统每年产生5亿美元收入并被数百万客户使用，这两者之间是有差别的。
某个职位的影响范围有多大？通常会直接影响多少工程师？例如，在一家小公司里，首席工程师的影响范围可能是大约10名工程师。而在像Uber或谷歌这样的大公司里，这个范围可能是100名工程师甚至更多。这两个职位在头衔上相同，但在期望上却非常不同！
典型的资深工程师及以上职位的期望
“资深工程师及以上职位”（Staff+ Engineer）是我在本书中用来指代高级工程师之上的级别，包括资深工程师、首席工程师及更高级别的头衔。
资深工程师及以上职位的头衔和期望差异很大。以下是我尝试总结的大型科技公司和较大规模初创公司中常见的期望。需要注意的是，对于那些首席工程师（Principal Engineer）位于资深工程师（Staff Engineer）、杰出工程师（Distinguished Engineer）或研究员（Fellow）之后的公司，其期望可能会高于这里列出的内容。
资深工程师及以上职位是工程经理（EM）和产品经理（PM）的合作伙伴
在大多数拥有个人贡献者（IC）和管理者双轨职业发展路径的大型科技公司和规模化初创公司中，资深工程师通常与工程经理（EM）或高级产品经理（PM）处于同一职业级别。这不仅仅是象征意义；它还表明资深工程师及以上职位需要成为工程经理和产品经理的合作伙伴。对于更高级别的资深工程师职业级别来说也是如此。例如，在Uber，首席工程师（L7）与工程总监（L7）处于同一职业级别。同样在Uber，首席工程师被期望成为工程总监和产品负责人（PM）的合作伙伴。我们在第一部分“职业路径”中讨论了双轨职业发展路径。
这种期望通常是未明说的，需要资深工程师及以上职位的人员主动努力，投入时间来加强这种合作伙伴关系。正如任何合作一样，使其成功的关键在于信任；工程经理和产品经理需要付出努力完成重要的事情，并保持开放的沟通。
作为一名资深工程师（Staff+ Engineer），你通常会面临比你能够轻松处理的更多工作。那么，如何确定应该专注于哪些对业务有利的工作呢？要回答这个问题，必须理解业务。
在不太关注业务的情况下，你可能仍然能够在职业生涯中成长到资深工程师的级别，但如果没有这方面的知识，要在资深工程师的岗位上取得成功并进一步成长将非常困难。虽然软件工程、长期规划和协作等其他方面的职责同样重要，并且是你在职业生涯中可能已经强化的技能，但理解业务是不可或缺的。
北极星指标、KPIs 和 OKRs 的概念对于大多数软件工程师来说似乎既无聊又无关紧要。当 CEO 谈论 OKRs，或者产品经理讨论 KPIs 时，软件工程师往往觉得这些内容缺乏吸引力，因为我们更喜欢具体的内容。相比于讨论 OKRs 和 KPIs，我们更倾向于关注具体要做的项目以及为什么要做这些项目。
对于单个工程团队来说，讨论项目的具体内容及其影响是很容易的。但随着团队数量的增加，你不能仅仅列出每个团队计划要做的事情；此时就需要退一步，从更大的视角来看问题。而这正是北极星指标、KPIs、OKRs 和路线图发挥作用的地方。作为一名资深工程师，你需要理解这些概念为什么重要以及它们的含义，并将这些内容传达给团队中的工程师，让他们明白应该关注什么以及为什么关注。
这些概念如此重要的另一个原因是，大多数资深工程师都是工程经理（EM）和产品经理（PM）在定义团队战略和路线图方面的合作伙伴。为了与 EM 和 PM 使用相同的语言：北极星指标、KPIs 和 OKRs 是非常有帮助的工具。
这是一个团队或产品的愿景；它引导这些事物达到目标。例如，一个内部支付团队的北极星指标可以是：“让公司内的任何团队在一天或更短的时间内将支付功能集成到他们的产品中。
北极星指标通常是雄心勃勃且不简单的——甚至可能是暂时无法实现的！这是有意为之的，因为它具有激励作用，旨在让团队成员保持动力和专注。一个好的例子是航天工程公司SpaceX的北极星指标：将人类送上火星。通过专注于这个目前无法实现的宏伟目标，公司通过逐步改进，一步步接近目标。这就是任何团队或公司设立北极星指标的目的。”
北极星指标的度量是捕捉向目标迈进的进展，例如客户数量、每日活跃用户等类似数据。
KPI代表关键绩效指标（Key Performance Indicator），是衡量某一领域进展的量化指标。大多数北极星指标都可以通过KPIs来体现。以下是一些常见的例子：
流失率百分比：在给定时间段内未复购的客户占总客户基数的百分比。通常以一个月或一个季度为周期，用于获取最新反馈。
还有无数其他KPIs，例如客户生命周期价值（CLV）、客户获取成本（CAC）、报告的错误数量，以及其他任何你能想到的指标。一个好的KPI是可衡量的、明确的，并能帮助指示进展和发现问题。一个好的KPI也很难被“操控”：即在没有实际改进的情况下让指标朝着正确的方向发展。”
目标与关键成果（OKR）是一种非常流行的设定和衡量目标的方法，最早由Google在1999年引入，当时公司成立仅一年，员工约40人。这个方法是投资人John Doerr建议的，他后来写了一本关于该方法及其成功的书《Measure What Matters》。
采用OKRs的企业会在公司层面、组织层面以及团队层面设定目标。一个OKR由两个部分组成：
一个OKR总是有一个目标，但可以有多个关键结果。一些例子如下：
关键结果：
关键结果：
关键结果：
如果你的公司使用OKRs，从最高层开始了解领导层关注的目标和关键结果。弄清楚你的团队如何为这些目标做出贡献。
与产品经理和工程经理合作，为团队制定对业务有意义且工程师能够理解的OKRs。你可能需要介入，将一些企业术语以及关键结果和目标的定义进行翻译和解释。
不要过于执着于OKRs。它们是一种帮助团队聚焦的工具，类似于工单系统等工具可以提高效率。然而，与任何工具一样，OKRs也存在被过度使用的风险，可能会让团队过于专注于实现某个特定结果，而忽视为客户构建正确的产品。
优秀的工程团队与普通团队之间的显著区别之一在于，“优秀团队”的工程师会质疑产品团队提出的KPIs甚至OKRs。对于模范的资深工程师及以上级别的工程师，我认为这种质疑是理所当然的。
质疑每一个提出的衡量指标，并从多个角度进行调查：
不要忘记更大的图景。衡量系统特性比衡量客户满意度、客户挫败感或客户转化率和流失率要容易得多。如果只专注于非常具体的衡量指标，这些关键细节可能会被忽视。
了解业务运作的最佳起点是你和团队正在开发的产品。理解这个产品是如何工作的，客户为什么使用它，它的竞争对手是谁，以及它如何为公司的盈利做出贡献。
你的团队有专职的产品经理吗？如果有，那太棒了；这是你可以——并且应该——合作的对象。如果没有，产品经理的角色仍然需要有人来承担，所以可以考虑由你来完成。
尤其是对于面向内部的工程团队，比如构建技术产品的平台团队，通常没有产品经理。我们在第一部分《在不同环境中茁壮成长》中对平台团队有更多的讨论。
然而，即使在这些团队中，仍然需要有人承担与产品相关的活动，以提高团队的效率，包括：
在没有专职产品经理的情况下，戴上你的产品经理帽子，开始处理上述活动。如果你确实有专职的产品经理，与他们合作。也许你可以帮助完成这些活动。
为什么你需要花费大量时间和精力去了解客户？因为理解客户如何运作是你发现需要解决的客户问题的途径。
“资深工程师与高级工程师及以上级别工程师之间的一个关键区别在于：解决问题与发现问题。高级工程师和资深工程师都需要解决具有挑战性的问题，但资深工程师还需要发现值得解决的问题。站在客户的角度思考是最显而易见的方式之一。
如果你不是正在开发的产品的常规用户，尝试成为一个！对于消费类产品，尤其是解决某些问题的产品，这会更容易。例如，当我加入Skype时，我已经在使用该视频通话服务与朋友联系，因此我已经是用户。然而，对于某些类型的产品，这可能会更棘手：
当客户是内部用户时：尝试使用测试账户或其他方式观察“客户体验”。这对于建立同理心和与客户更接近非常有帮助。
参与客户支持。这是站在客户角度的最佳方式之一。阅读客户支持工单，聆听客户支持电话。更好的是，与客户支持人员交谈，他们可以总结用户最常见的问题，并分享客户情绪随时间的变化。”
“客户为什么使用我们？”这是一个显而易见的问题，但工程师经常没有答案，这令人惊讶。作为资深工程师及以上级别的工程师，你不能不了解这一点。所以去找答案吧！以下是方法：
阅读评论。浏览用户评论，这些是主观的个人意见，同时也可以查看知名产品的分析师评论，以及可能包含竞争对手信息的媒体文章。
如果可能的话，注册竞争对手的服务并以用户的身份进行评估。对于消费类产品来说，这很简单，但对于企业类产品可能会困难得多。与产品团队讨论他们如何评估竞争对手，并查看是否可以使用现有账户来分析竞争对手的产品。
分享你的观察的一个好方法是创建一份包含你产品和竞争对手的“比较文档”。这可以帮助将知识传播给团队的其他成员。特别有用的比较内容包括：
为什么你的公司投入大量资金和精力来构建你的产品？投资回报是什么？回答这些问题的最简单方法是询问你的产品经理或工程经理。不要接受浅显的答案，深入了解为什么业务会投资于你的产品和团队。
产品通常可以根据其对业务的贡献分为两类：
我们在第一部分《职业路径》中详细讨论了利润中心和成本中心。以下是一些问题，用于识别你的产品属于上述哪一类，以及它如何与业务价值相关：
SWOT代表优势（Strengths）、劣势（Weaknesses）、机会（Opportunities）和威胁（Threats）。这是一个描述产品及其所处“商业环境”的规划文档。
研究这四个领域，将其整理成文档，并与产品团队和团队成员分享以获取反馈。这个练习会迫使你像业务所有者一样思考并理解竞争对手。完成后，你会以更具战略性的方式看待你的产品。
在公司内部是开始理解业务的最佳方式。有很多方法可以感受公司是如何运作的。让我们逐一探讨。
你的公司如何赚钱？它如何将收入转化为利润并管理成本？如果它尚未盈利，实现盈利的计划是什么？
在初创公司中，亏损较长时间是常见的，可能需要数年才能实现盈利。了解单位经济学以及公司需要达到的目标以实现盈利仍然是值得的。单位经济学指的是生产单个产品或服务单位的成本。
例如，在Uber的早期阶段，一个新城市的每次行程的单位成本可能是其带来的收入的两倍。
对于上市公司，季度业务结果是公开的，可以提供最近业绩的概览。在这些公司，你通常可以在活动后获得最新财报电话会议的录音或文字记录。评估这些资源可以帮助你更好地理解公司的商业模式以及当前的关注点。
为了理解公司如何赚钱，熟悉以下领域可能会有所帮助：
产品经理是业务与产品之间的“粘合剂”。他们需要对业务有出色的理解，并了解他们的产品如何影响绩效和增长。为了更好地“理解业务”，与这些人交谈吧！可以考虑从与产品人员的一次性会议开始，询问他们业务是如何运作的，以及他们的产品与业务的关系。
一些资深工程师犯的一个错误是只与工程师和产品人员联系，而忽视了更广泛的业务领域。不要这样做；拓展你的视野。
考虑与以下人员交谈：
尽管听起来有些反直觉，但偶尔与公司内与你的产品毫无关联的人交谈，了解他们的工作内容、如何为业务提供帮助以及他们与工程的联系，这可能是有益的。大多数情况下，这种类型的对话在短期或中期内没有直接收益。然而，它可以帮助你开阔视野，并与业务中完全不同领域的人建立个人联系。从本质上说，这是一种建立人脉和学习的机会。
产品经理通常是直接与对你构建的产品感兴趣的业务利益相关者沟通的同事。产品人员捕获需求和期望，同时也与业务利益相关者设定现实的期望，并向他们传达正在构建的内容。
作为资深工程师，你需要与业务利益相关者交谈吗？如果你有一位非常出色的产品经理，他们能够捕捉细节并与这些人建立强有力的联系，那么答案可能是“不需要”。产品经理可能已经掌控了局面，而另一个人（你）与业务利益相关者交谈只会增加负担。
然而，通常情况下，与业务利益相关者会面并在一对一交流中给予他们你全部的关注，是一项非常高效的活动，你应该去做，因为：
作为资深工程师，你需要成为业务的合作伙伴。但如果你从未与业务同事交谈过，又如何成为一个优秀的合作伙伴呢？根据我的经验，科技公司中的业务人员非常愿意与资深工程师进行一对一交流。这是因为他们通常认为自己的领域几乎没有直接受到工程团队的关注，尽管他们的成果在很大程度上依赖于工程工作。基本上，建立联系符合利益相关者的利益。
哪些业务领域对你来说是有意义的对话对象？以下是一些建议：
识别这些团队——你的产品经理可以帮助完成这项工作。然后，与合适的人安排一对一交流。主动联系他们，表明你有兴趣了解他们的业务领域，以及工程如何能够帮助他们。我还没有见过有哪个业务部门会拒绝一位想要帮助并寻求信息的工程代表！
当领导层召开全员会议、城镇会议，或向大组发送电子邮件时，注意他们所说的内容。如果这些信息是间接传达的，试着弄清楚真正的信息是什么。
在资深工程师的级别，你可能已经习惯了领导层以间接方式传递信息，并用语言以“需要解读的方式”来传达敏感内容。例如，CEO很少会直接说某个领域在接下来的时期会被降低优先级，即使事实确实如此。但可以通过一些线索推断出这些事实，例如：
在重大公告之后，与产品经理和工程经理交谈，以确认你是否正确理解了“真实”的信息。作为资深工程师，有必要翻译领导层使用的企业语言，这是一项需要实践的技能。
如果你的客户是消费者或外部企业，找到方法从这些人那里获取反馈。以下是一些方法：
作为资深工程师，你应该已经在工程战略和规划讨论中占有一席之地。然而，你可能不会被邀请参加产品战略和业务战略讨论。
但参加这些会议是拓宽你对业务理解的绝佳方式。所以努力争取参与，旁听一些会议。与经理或产品经理交谈，要求参加一个可以倾听和学习的会议。他们不太可能拒绝这样的请求！
获得对业务更广泛的理解最简单的方法就是参与涉及多种工程和业务团队协作的项目。作为资深工程师，你更有可能被分配到这类项目中。
然而，如果你在资深工程师的岗位上没有参与此类项目，主动寻找这些机会是有帮助的。以下是一些方法：
在与经理的一对一交流中，询问你尚未完全理解的业务部分。你的经理可以为你澄清问题，或者为你提供搜索方向的指导。即使一些经验较少的工程经理尚未意识到这一点，清晰地理解业务对他们和你自己都有好处。
与跳级经理以及其他工程领导者进行一对一交流。当我在Uber工作时，一位负责开发者平台的工程副总裁（我合作过但不属于的团队）访问了我们的办公室，我与他们进行了一对一交流，以了解他们团队的工作内容。结果发现，这位副总裁想更多地了解我们团队在开发工具方面的痛点。我学到了很多关于开发工具的知识，以及如何互相帮助。随后，我邀请这位副总裁与我们团队的一位资深工程师进行一对一交流，他们愉快地同意了。我们团队的资深工程师从那次对话中获益良多。
后来，当一位经验丰富的资深工程师加入我们的组织时，他们主动安排了这样的对话，而不是等待经理来安排。事实上，他们几乎与整个管理链以及跳级经理的同级进行了交流，以了解业务以及工程领导层关注的重点。不出所料，这位资深工程师识别出了“低垂的果实”项目以参与其中，并确定了优先处理的项目。
在大型科技公司以及许多成长型科技公司和初创企业中，产品经理通过撰写产品需求文档（PRD）来将业务想法转化为功能或产品。这些文档通常记录了业务目标和产品的拟定功能。
花时间阅读与你业务领域相关的PRD，并在发现不清楚的地方提问。定期这样做将帮助你保持与业务方向的联系。了解这一方向将有助于架构决策，例如如何发展基础设施以支持已在多个PRD中记录的几个相关产品计划。
如果你的公司没有撰写PRD或产品经理以书面形式捕捉规范的文化，你需要寻找替代方法来保持对产品方向的了解，例如与产品人员交谈。
与不认识的同事见面和交谈可能会有所收获，尤其是在不占用太多时间的情况下。以下是一些建议：
在这些情况下，我发现了解人们工作的领域、该领域的特别之处以及他们面临的挑战是很有趣的。此外，我总是对他们如何与技术和工程合作感兴趣，以及是否有我可以帮助的地方。
我发现与业务中不同部分的人见面是一次开阔眼界的经历，尤其是他们的工作方式与软件工程的差异，以及“主要挑战”在不同领域意味着完全不同的事情。
偶然的会面通常不会立即产生可操作的结果。但只要它们不占用太多时间，应该是有趣的。这类会面可能为未来的合作埋下种子，或者建立与业务不同部分的联系。
“为什么很少有工程师与业务利益相关者会面？
根据我在大型科技公司工作的经验，以及与其他地方的同行交流的结果，很少有工程师主动联系业务利益相关者。这是为什么呢？我观察到的常见原因包括：
在许多情况下，工程经理并不直接与业务利益相关者交谈，认为这是产品团队的工作。因此，工程师缺乏动力去这么做。在一些“政治化”的公司中，如果经理不与业务接触，工程师主动联系业务可能会被视为“捅娄子”。
对于那些没有与主动联系业务利益相关者的同行共事过的工程师来说，他们没有这样的“榜样”，即使这些工程师已经变得更加资深，也不会想到要这么做。
当工程经理、产品管理或公司的领导层没有鼓励工程师直接与业务合作，或未能强调这种合作的案例时，工程师自然不会想到要这么做。”
一些公司声称工程师是以产品为中心或以客户为中心的，但实际上存在一种分离，导致业务无法与工程部门真正互动，反之亦然。
许多公司采用更“传统”的管理风格，倾向于由关键人物（通常是经理）收集和分发信息。这可能包括非正式和正式的结构，使得“个人贡献者”获得信息的渠道较少，也缺乏分发信息的机会。大多数大型科技公司并非如此运作，但我观察到不少初创公司在成长过程中因领导层未能有意建立透明文化而逐渐形成这种现象，同时也未能赋予工程师决策权。
在一些公司中，工程团队被视为“功能工厂”，工程师被期望按照指令行事，几乎没有自主权。在这些公司中，工程师被劝阻与业务利益相关者交谈，因为这被认为是浪费时间。毕竟，产品经理和项目经理已经在做这些事情了！”
如果你在一家上市公司工作，每三个月就有一次机会了解业务的运行情况。这就是季度财报周期，其中包括在最新财务结果发布后与相关方进行的收益电话会议。
上市公司必须在季度报告中披露关键信息，其中领导层会回答分析师和记者的问题。这些电话会议通常面向投资者、利益相关者和媒体，但作为员工，你通常可以找到一些未在内部传达的信息。
季度报告和投资者电话会议中的有用信息：
理解诸如借贷、净收入、现金流和EBITDA等术语的含义，可以让你对公司的财务状况有深入的了解。这些是普遍适用的知识，如果你未来创办自己的公司或有机会担任高管职位，这些知识可能会有所帮助。
一个很好的入门资源是Modern Treasury的《Accounting for Developers》。另一本对理解业务思维有帮助的书是Josh Kaufman的《The Personal MBA》。
与上市公司不同，初创公司不会每季度报告其财务状况，也不会面对分析师的尴尬提问。然而，初创公司往往具有更高的内部透明度。所以，利用这一点吧！
如果你的初创公司默认是透明的，你应该能够访问业务指标，并了解业务的进展情况、增长领域和挑战。如果不是，主动询问相关信息。对于一位经验丰富的工程师来说，几乎没有理由不分享这些细节。毕竟，这些信息有助于改进关于工作内容的决策。
如果你的初创公司规模足够小，你可以直接接触到创始人，那就抓住这个机会。偶尔与创始人会面，了解他们对业务的思考方式，以及他们的优先事项和业务目标。询问与投资者的关系，以及投资者和董事会的优先事项，从而了解公司的整体情况。
如果你的初创公司正在筹集新一轮资金，询问是否可以查看融资计划书。这将描述你的初创公司目前的状况以及希望达到的目标。了解这些目标将使你更容易决定哪些工作应该优先完成，哪些可以暂时搁置。”