我非常幸运地在Heroku度过了令人惊叹的5年。在我工作结束的时候，我是以员工的身份运营的，尽管老实说，我完全不清楚Salesforce的哪些头衔实际上是与员工对应的。
因为标题不清楚，而且我的角色有点不确定，所以我选择不把故事提交给威尔·莱森在StaffEng.com的伟大收藏品。话虽如此，我在他的问卷中添加了几个我在其他地方没有看到答案的问题，所以我想我应该把这个贴出来。
告诉我们一些关于你目前的角色：你在哪里工作，你的头衔，以及你和你的团队通常做的工作。
直到最近，我还是Salesforce的首席工程师，为他们的Heroku产品工作。大约五年前，我加入了Heroku插件产品，然后转到Heroku API团队。在过去的一年半里，我在Salesforce Functions产品的API团队工作，该产品运行在Heroku基础设施之上。
API团队是定义Salesforce Functions产品工作方式的核心，因此我们团队要完成很多不同的任务。首先，也是最重要的是，我们编写代码来存储客户希望其基础架构聚合到的状态，然后将其下推到基础架构层。如果您正在与Salesforce函数交互，那么您需要检查我们的代码。我们还做了很多协调基础设施能做什么与产品的希望和梦想的工作。我在工作中取得了平衡，但更倾向于“希望和梦想”的一面。
在贵公司，一个“普通”的员工加工程师是做什么的？你的角色看起来是这样的呢，还是有所不同？
Salesforce确实没有“普通”的员工工程师。我通常会谈到我在公司中看到的四种不同的方式，其中一些符合威尔的原型，另一些则不符合。很多人是这两种方式的混合体，在公司漫长的职业生涯中轮流使用这些方式。
您是一个或多个团队中10-20名工程师的主要技术联系人。您通常向经理的经理汇报工作。责任根据个人的长处和他们经理的长处而有所不同，但有一些共同的事情你必须做。如果您没有制定交付时间表，这会让您的组织大吃一惊，那么您和您的经理就有麻烦了。如果产品有一个梦想，但没有人知道构建它需要什么(时间、资源、架构)，那么你就有问题了。如果你不能回答“为什么我们要以这种方式建造它？”那你就有麻烦了。
如果它出现在TechCrunch上，或者在我们的公司会议上进行推广，那么就会有一个架构师。如果项目(40多名工程师)未能成功，您将与(通常)副总裁+工程经理和产品负责人共同承担责任。如果你有任何形式的个人存在，你就会被放到舞台上，出现在客户面前。这是你与你的副总裁一起帮助倡导主要计划去追逐特定市场的水平。如果我们下了错误的赌注，有些责任在产品上，但也有责任在你身上，经理可能看起来不会很好。
您在特定组件或系统方面有很多深厚的技术专长。你倾向于留在一个团队或组织的一个单一领域。如果你在我们的遗留代码库中工作，这是我们盈利能力的核心，你基本上是不会着火的，因为你知道的太多了。您可能会为您保留的遗留系统中的一些最棘手的问题编写代码，但是您经常会发现自己花了更多的时间与其他团队交互，以解释为什么您的系统不能做他们想做的事情，以及我们如何解决这个问题以在合理的时间线内交付。您将每天/每周与您的团队领导密切合作，偶尔您的一整天/一周都会被夸大，因为产品架构师发现需要您的专业知识，突然之间您被带到某个您从未听说过的团队进行演示。
有两种变体。首先，你正在摆出直线经理的位置，但由于你的IC头衔与董事或副总裁的级别相同，让你成为经理将导致大幅减薪。考虑到Salesforce的目标是12-15份报告，你可能在管理一个较小的团队。在第二个变体中，您大致是VP+领导的延伸。也许您正在研究如何让我们的数千名工程师保持良好的沟通。也许你是在建议高级副总裁在哪里进行技术投资-我们公司真的有足够的竞争优势去追逐这个市场吗？当然，高级副总裁/高级管理人员被“产品”告知，只要你给我们1亿美元，我们就能做得很多。这是真的吗？嘿，我们刚刚买了一家数十亿美元的企业(或者我们即将买下)：你能想出我们应该怎么处理它们吗？包括威尔在内的许多人称这是救火，但对于这些角色如何真正为大公司带来价值来说，这样的观点太狭隘了：这是快节奏的机会侦察和说真话。这就是说，你很可能会在业务中更具挑战性的部分寻找机会和真正的真相，所以我看到了救火的类比。
首先也是最重要的是，如果与我共事的人了解商业决策是如何与他们的日常工作联系在一起的，我就是成功的。
至少，这涉及到相当多的理解为什么我们会被要求建造一些东西，跑在团队之前以确保我们的产品计划已经到位，跨团队合作提出一个可实现的计划，然后在IC问题突然出现时支持它们。
但这也意味着推进关于目前在我们的代码中哪些类型的风险值得承担的讨论。现在是致力于这一抽象的合适时机吗？现在是通过重新架构来解决性能问题的时候了吗？我们行动迅速，但也看到了很多事件--我们应该投资于什么类型的测试？
成功看起来就像是看到IC之间关于时间表和优先级的对话从一个共同的背景开始。成功看起来没有关于“你怎么能建议我们发运这个黑客？”的重大爆炸事件。取而代之的是，人们可以从商业的角度谈论技术选择：“我知道与我们的产品雄心相比，我们目前的员工数量较低，但这是简化的正确地方吗？”成功看起来像是一个团队，对我们正在编写的代码的质量和弹性有着共同的目标。成功看起来也像其他IC一样，对倡导变革充满信心，因为他们看到我们的团队在做出技术决策时心中有一致的目标。当我在1：1的时间里与IC交谈时，当涉及到代码、基础设施和事件时，不应该有“我不确定我为什么要做X”这样的话。
其次，当我的管理层清楚地了解我们正在承担的特殊风险时，我就成功了。团队做出的所有架构决策最终都将是错误的。无论技术变化，我们的客户群变化，还是产品本身变化，我们后悔这些重大选择只是时间问题。关键是要了解我们下了什么赌注，在我们需要重新考虑这些赌注之前，我们会考虑多久。
大型企业的架构在很大程度上是关于风险管理的。一家大型机构在市场上有很多现有的动能，自然会变得更加谨慎。我只有几个地方可以提倡高风险的押注，这些押注的风险将比初创公司低得多。虽然我需要接受这样一个事实，即我们的决定将是错误的，但我需要能够谈论我们可能出错的方式、我们何时知道以及我们的缓解策略将是什么。
第三，如果我对我的经理说了正确的“不”，我就是成功的。如果向我的经理汇报的IC最终感觉像是“我告诉过你了”或“我们知道这是个坏主意”，而这并没有浮出水面进行讨论，那就是我的责任。作为一名员工工程师，当我们过度承诺或致力于错误的事情时，我有责任纠正我的经理。
最后，如果我的组织拥有健康的工程文化，我就成功了。没有人拥有文化，但这并不意味着我们不能平等分担建设世界级工程组织的重担。
虽然我确实会时不时地编写代码，但只有在我完成了对这四个功能的义务之后才会编写代码。
信息收集-为了帮助我的团队了解我们正在构建一件事情的上下文，我需要大量的信息。我几乎无懈可击地以一长串电子邮件和各种需要消化的文档开始我的一天。我还花了相当多的时间与各式各样的经理和高管进行跨组织的聊天，他们的目的是收集信息和我下面提到的指导相结合。
计划--知道一大堆东西是没有用的，除非我们真的去做一些事情，所以我也花了很多时间来计划活动。这是大量撰写文档和召开会议的工作。计划活动通常是非常协作的--我很少对任何一件事知道得最多，但我可以把它们编织在一起，形成一个计划。
上下文共享-除非很多人理解计划，否则知道我们想要做什么是没有帮助的，所以最后一类面向执行的工作就是共享所有的上下文。我与其他团队一起参加会议，分享我们正在做的事情，我审查公关，以确保我们做出的小决定与更大的目标保持一致，并举行站立团队1：1的会议，以确保每个人对我们前进的方向充满信心。
培训与企业文化--最后一类工作并不以交付产品为导向，但对我们组织的长期健康而言，投资于我们的工程师仍然是至关重要的。我个人的做法更多的是投资于人，而不是在过程中。鉴于我在个人生活中对日历、电子表格和流程的热爱程度，我想说，这种做法在很大程度上是对在大公司环境中工作的非人性化本质的一种反应。我在1：1的时间里花了相当多的时间，对初级员工进行一些指导，但主要专注于指导我们的高级工程师，他们实际上很少有机会获得建议。每隔一段时间，我都会尝试一下我们的正式流程，就像我在我们的~120人组织合并到更接近Salesforce后帮助重组我们的增值税团队时所做的那样。
我也最终成为进入我们团队闲置频道、公关和文档评论帖子的外部人员的RACI执行者。对于报告较少的经理来说，或许可以每天都跟上这一切。我的会议负担较轻，可以带着不同的“谢谢你的意见，我们会记住这一点”的形式加入进来。我的理解是，你们的团队不会分担这一决定的责任。“。我自信地利用我经理的权威进行交易，我的队友可能会为此而苦苦挣扎。由于我的时间和我对正在讨论的技术细节的更深层次的参与，如果技术对话开始绕过排水沟，我有责任介入并降级。大多数情况下，我可以解决这个问题；很少情况下，我需要在他们的会议之间拉来我的经理或跳级，以帮助驾驭一些奇怪的跨团队动态，这会导致某人无意中对我们的IC有点无礼。这意味着，我在会议间隙(以及更无聊的时候)的大部分小瞬间都被文件、公关和帖子一页接一页地循环着，看着今天的交流是如何进行的。
当您在实践开发上花费的时间更少时，您如何保持与事物实际工作方式的联系？
作为偶尔仍会编写代码的人，这是我努力解决的问题。我们的代码库在我的脚下不断地变化，这是我经常看不到的。这是我今年的目标，确保我说“我不确定，让我检查一下”，即使我觉得很有信心。
您是如何赞助其他工程师的？赞助其他工程师是你角色的一个重要方面吗？
是。每个人都想雇佣高级工程师；没有人想要制造他们。那真是一团糟。指导和指导只能到此为止-你需要为人们提供在伸展任务中成长和失败的机会。
我的团队内部的赞助工作与我还是一名高级工程师时一样-我会与我的经理和团队讨论谁在做什么工作，并提出建议。作为一名员工工程师，我有了新的机会来赞助整个组织中的人们参与我所做的一些组织协调工作。对我来说，这通常看起来像是邀请某人作为特定技术交流场所的后备人员，无论是书面文件还是会议。我会花时间确保这个人理解他们工作的背景，并回答他们可能有的任何问题。我会明确询问他们对参加/参与/领导一个特定的交流场所有多大的信心。最后，我会转到从阴影中观察，偶尔做一次汇报，检查他们的信心和了解组织动态的能力。一旦他们感到自信，除非他们明确要求，否则我就该停止参与了。
作为一名员工级工程师，赞助是解决时间浪费问题的关键途径。然而，你现在需要花时间来培养人。你很容易陷入水下，以至于你实际上没有足够的时间来指导和指导某人，以至于你可以赞助他们从你的盘子里拿走一些东西。及早投资赞助开始以一种健康的方式打开你对委派的眼界，而不仅仅是向某人倾倒一些东西。
能够在组织内部建立联系，以帮助更快、更少地交付计划，这是成为一名员工工程师的关键能力。然而，在远程设置中，这可能会感觉有点困难，需要专心致志的努力。
我一开始就养成了在会议结束后伸出援手的习惯，即使只是想说很高兴见到你。通常情况下，这会转化为你在办公室环境中可能无意中接触到的一些个人联系：某人是如何进入科技行业并从事这份工作的？他们工作之外的生活是什么样子的？他们看起来真的在做最新的项目吗？
对于那些似乎对此持开放态度的人，我试着安排一个虚拟的咖啡休息时间。有很多工具可以为您的团队自动执行此操作，如Donut.ai。我发现随机分配工具的时间可能远远超过它们的价值，但如果您的公司有这样的工具，它是设置东西时参考的一个有价值的工具-它会让您的要求看起来更随意。
这可能会让人感觉怪异--这是可以接受的，也是意料之中的！问一些开放式的问题，目的只是为了了解某人，通常你的联系人会很乐意分享让他们兴奋的事情。
确保你向与你交谈的人提供信息和价值。热切地借用您的人脉和专业知识。深入倾听某人正在做的事情和面临的挑战，并分享他们可能会看到这些的背景。随着你在组织中的地位越来越稳固，你可能会发现提供价值变得越来越容易。无论是可行的(“哦，就这一点与某某人在法律上谈一谈”)，还是与背景相关的(“哦，那是因为某某讨厌这次收购”)，分享你能帮助他人的东西是将你的人脉凝聚成一个网络的原因。
如果你在一家公司站稳脚跟，要意识到你很可能严重依赖于过时的组织观念。你可能会进一步加深现有的误解或宿怨，而这些误解或宿怨真的应该消失了。积极投资结识新朋友，以此作为一种平衡。
如果你是新人，相信你的外部视角真的会给你周围的人带来额外的好处。试着找一个最有经验的人，他仍然会诚实地和你说话。这通常涉及到比你预期的级别更高的职位。