# Staff工程师到底是做什么的？ > Staff+工程师的角色很大程度上取决于团队的需求，以及特定工程师的优势。从我的经验来看，Staff+工程师的职责会随着时间的推移而改变。尽管如此，通常情况下，他们的主要关注点仍然是对公司具有战略价值的项目/努力方向，同时推动技术设计和提升他们的团队。 > > \- Diana Pojar 任何一个在聚会上被亲戚堵在墙角、被要求解释软件工程师到底在做什么的人都知道，解释软件工程师的工作是很有挑战性的。随着时间的推移，你可能已经为你的亲属创造了一个令人信服的答案，但当同事靠过来问:“Staff工程师是做什么的?”时，许多人的大脑还是会一片空白。 最直接的一种答案是，Staff工程师一直在做那些让他们成为Senior工程师成功的事情:建立关系、编写软件、协调项目。然而，这是一个误导性的答案。Staff工程师也做这些的工作，但是以前这些是他们工作的核心，现在他们是辅助任务。他们的日常日程因原型而有所不同，但所有原型都有一个共同的基础: * **设定技术方向** * **提供辅导和支持** * **将工程背景注入组织决策** * **探索** * 以及Tanya Reilly所说的**作为粘合剂**。 ## 设定技术方向 > 当我能够帮助设定一个领域的技术愿景，并让人们朝着这个愿景前进时，我感到最有影响力。我想我们都同意，我们希望我们的代码架构能变得更好，或者在某些方面得到改进。然而，我发现人们往往有一些模糊的想要更好的感觉，但并不清楚他们想要的是什么。我喜欢帮助团队决定他们想要达到的目标的共同理解(如果我们从未达到目标也没关系)，并提出一个如何达到目标的总体计划。 > > \- Joy Ebertz 就像Lorax在他那本受欢迎的儿童读物中为树木发声一样，Staff工程师代表着他们公司的技术。技术不能为自己说话，它需要有效的倡导者为它说话。那些成功推动技术进步的人是务实的、深思熟虑的，他们更关注长期的发展趋势，而不是把每一个决定看作是成败的危机。你也可以认为你有时候需要扮演一个兼职技术产品经理的角色。 某些情况下，Staff+的工程师的工作是明确的——领导特定的领域，比如API设计；在其他情况下，他们发现自己需要去改变、适应各种业务。无论你的角色是什么，一个不变的事实是，设置技术方向更多地是关于理解和解决您周围组织的真实需求，而不是优先考虑您个人想要了解的技术和方法。在较早的角色中，您可能试图影响对您所激励的技术选择的决策;在高级职位上，你首先要对公司和组织负责，其次才是对自己负责。 ## Mentorship和Sponsorship > 在我目前的工作中，当我sponsor的人向我宣布他们已经发布了他们的工作时，或者当我看到我帮助塑造或改变了一个重要主题的工程团队的模型时，我感到充满干劲。是这些团队，而不是我，每天都在努力构建和支持他们的技术。我根据他们的进展来衡量（我的）影响力、他们的进展的方向以及他们的工作与公司目标的一致程度。 > > \- Michelle Bu 有一种流行的英雄式领导的观点认为，英雄式领导的核心是那些非常多产的个人，他们的决定会改变公司的未来。大多数故事都是公关团队为了创造一个好故事而特意设计的。你更有可能通过培养身边的工程师来改变公司的长期发展轨迹，而不是通过个人英雄主义。培养你周围的人的最好方法是建立一个积极的指导和支持的实践。 有时候，人们在自己的职业阶梯上看到了对导师的要求，并试图机械地检查这个框，这是一个遗憾，因为导师是Staff+员工角色中最有价值的活动之一。分享你的经验和建议，以及建立一种持续的关系，以了解接受者的背景，是一项具有高度影响力的工作。最有效的Staff工程师将适度的mentorship与相当多的sponsorship结合起来:把你的拇指直接放在天平上，帮助你提升和支持你周围的人。如果你还没读过，Lara Hogan写了一篇关于sponsorship和mentorship之间区别的经典文章，[What does sponsorship look like?](https://larahogan.me/blog/what-sponsorship-looks-like/) ## 提供技术视角 > 我参与了更高层次的工程讨论，这些讨论发生在单个项目和团队之上。我们经常召开员工工程会议，讨论跨团队的技术和非技术问题。 > > \- Dan Na 有效的组织简化了常规决策。为潜在企业客户审查合同的过程就是一个很好的例子。在早期，会签订一些产品和工程团队不愿意支持的合同。在这发生几次之后，流程将在评审步骤中包括更多的涉众，随着时间的推移，正确的人将在正确的时间出现在正确的地方。 即使是那些擅长做常规决定的公司，当意外的决定出现时，也会遇到困难。这类工作既对时间敏感又很重要，而且在做出决定之前把合适的人召集在一起是很有挑战性的。组织重组经常发生在没有什么决定性的理由的情况下。类似地，对于不太频繁的职位——那些你可能每年只雇佣一个人的职位，比如早期公司的高管或Staff工程师——没有对候选人进行重要的评估却没完没了的面试也很常见。对于一些公司来说，甚至像Roadmap Planning这样的事情也会出现这种状况。 Staff+工程师往往会意外地被拉进这个房间，做出这样的决定。这让他们有机会在仍然有可能改变结果的情况下，将工程环境和视角注入到决策中。这些对关键决策的输入会产生极其重要的影响，并允许你将工程视角注入到其他可能被忽略的地方。只要记住，你代表的是整个工程领域的利益，而不仅仅是你自己的利益。 ## 探索 > 在我目前在孵化器的角色中，我整天都在做prototyping，但在我之前的Tech Lead角色中，我做了很多不同的事情。 > > \- Ritu Vincent 爬山是一种简单的优化算法。想象你正站在某个地方的一座山上，想要登顶。你转一个圈，找到附近的最高点，然后走到那里。一旦你到达那里，你再转一圈，找到你的新位置附近的最高点，然后到达那里。如果你坚持这样做，无论你站在哪座山，你都会到达山顶。然而，想象一下你在一个有雾的日子里这样做。因为你看不太远，你可能会到达附近的最高点，然后发现在你的视线之外还有一个更高的点。 爬山不能解决所有问题，但它非常有效，许多公司都在努力采取其他方法。这可能是一个以消费者为导向的公司努力支持企业交易，或者一个成熟的公司努力与一个较小的竞争对手的发布节奏竞争。甚至可能是，你当前的业务非常有价值，即使有价值的业务增长速度在下降，也很难优先考虑新业务。 从长远来看，公司要么学会探索，要么逐渐消失;这不是一个可以忽视的挑战。简单地指派一个精通登山的团队去做探索性工作是不可能的，所以许多公司采取了不同的方法。他们找到几个值得信赖的、拥有广泛技能的人，分配一些资源，几个月后再回头看看他们发现了什么。其中一个工程师通常是Staff工程师。 这也不总是探索一个商业问题——它可以是任何模糊的、重要的，但是公司的当前系统无法解决的问题。比如可能是会将您的基础设施成本降低一个数量级，可能是一个仅仅需要6个月而不是3年的多区域战略，可能是因为公司突然意识到主数据库只有三个月的磁盘空间、还没办法扩容(根据我的经验，这在快速发展的初创公司是一个非常常见的问题)。 这些是公司所做的回报最高、风险最高的工作。这项工作需要大量的组织信任，包括从企业获得足够的尊重——如果你失败了，这是因为问题本身的难度，而不是你个人原因。 ## 扮演粘合剂的角色 [Tanya Reilly](https://noidea.dog/)写了一篇很好的文章，叫做[Being Glue](https://noidea.dog/glue)，它抓住了成功的Staff工程师的另一个核心元素:做必要的，但通常看不见的任务，以保持团队的前进和完成工作。它并不光鲜，但高影响力的组织通常有一个或多个Staff工程师在幕后工作，加速最重要的工作，并确保完成它。 ## 但是你还写代码吗？ 当Staff工程师聚集在一个房间里时，如果不对他们提出的第一个问题发表意见而结束对Staff工程师角色的任何讨论是不礼貌的。这个问题就是：“您还有时间编写软件吗?” 答案当然是，看情况而定! Ras Kasa Williams说:“我仍然定期贡献代码——肯定比我团队中的其他工程师少;但重要的是，我要坚持'hand to keyboard'(脚踏实地)的工作，以确保我的技术战略(和其他宏观层面的决策)是基于我的团队其他成员的实地经验。” Katie Sylor-Miller说:“我是一名前端架构师，但到目前为止，我最近写的主要东西是SQL，因为我做了很多数据分析。我一直在研究我们的性能指标，以找出需要改进的地方，以及要改进性能和业务指标需要解决的最有影响的问题。我会在这里或那里编写一些JS或PHP，但主要是为了帮助解开团队阻塞或运行一些与性能相关的小实验。” Joy Ebertz说:“你的职位越高，你的工作与代码的关系就越少。当然，与人事经理不同的是，你仍然有一个非常技术性的倾向，即使在原则上，你可能至少要写一些代码。然而，你获得的职位越高，你的工作就越成为指导和发展你周围的人(更广泛地说)，通过建立公司的公共科技品牌来建立你的团队，注意可以改进或纠正的更大的技术趋势，帮助你的团队或公司设定技术愿景，并倡导为技术债务项目提供资源。” 大多数人写一些，有些不写，但没有人写得像他们在职业生涯早期那样多。偶尔也会有纯粹的编程周，但这并不是常态，**如果这种情况发生得太频繁，这通常表明你在做一些舒服的事情，而不是重要的事情**。即使你写的不多，你也会阅读大量同事的代码，并进行大量的代码评审。 ## 缓慢但是有成就感 Staff +工作的一个统一主题是时间跨度更长。在你职业生涯的早期，你很容易依赖于软件开发的快速反馈周期——编写、测试、发布、重复。而你在Staff+级别上要做的大部分工作将用耗时数周、数月甚至数年的反馈周期取代。当你第一次担任Staff+的角色时，这些较长的时间框架会让你感到意外地沮丧。如果作为Staff+工程师的你结束了一天的工作，却感觉啥也没完成——这是很正常的！要继续坚持下去! 发挥影响力和个人成长需要更长的时间，虽然我交谈过的每个人都希望他们偶尔能有更多的时间写代码，承认有时会担心自己没能完成多少任务，但他们中没有人后悔自己过渡到当前的角色。 --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://yucliu.gitbook.io/staff-engineer/gai-shu/staff-gong-cheng-shi-shi-zuo-shen-me-de.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.