身为资深工程师的我为何回避聚光灯
最近我一直在阅读肖恩·戈德克关于资深工程师的随笔。他的作品(尤其是《聚光灯下的软件工程》和《问题不在你的代码库》)锋芒毕露，让任何身处科技巨头的人都感到痛彻心扉的熟悉。
纸面上，我完全符合他描述的模板：身为谷歌资深高级工程师。然而阅读后，我始终感到隐隐不安。起初我将其归咎于愤世嫉俗，但反思后意识到问题不在肖恩的文字，而在我的解读。
肖恩并非在描绘黯淡图景，而是精准剖析工程师沦为可替代资产、优先级每季度更迭的生存法则。但我的工作与之截然不同，内心深处我清楚：若强行适应那种环境或照搬他的方法，数月内必将精疲力竭。
因此我选择了另一条道路——优先优化系统而非个人功绩，注重守护精神而非可替代性。
我们身处不同世界
我们道路分歧的根本原因在于：肖恩与我身处遵循不同法则的平行世界。
从肖恩的简历来看，他主要在面向外部客户的产品团队1工作。商业目标每季度调整，成功标准是营收或月活跃用户数。在这种环境下，为“聚光灯效应”优化产品完全合理。大型科技公司的产品开发如同拥挤的房间：副总裁、产品经理和用户体验设计师各执一词。要成功，你必须敏捷灵活，确保专注于高管当前关注的重点。
而我整个职业生涯都更偏向幕后：在开发者工具和基础设施团队工作。
我的团队服务对象是Android、Chrome及谷歌全公司数千名工程师2。谷歌产品的终端用户甚至不知道我们的存在；我们的核心使命是确保开发者能通过工具收集产品性能指标，并借助详细追踪记录调试问题。
在此环境下，我们与高层的关系截然不同。我们从来不是“人人争抢的热门项目”，因此高管们不会争相与我们合作。事实上，我的团队历来难以招聘产品经理。谷歌的产品经理职业晋升体系鼓励高调的外部发布，而我们无法为他们提供优质的“晋升素材”。此外，我们的反馈直接来自工程师。若在中间加入产品经理，会造成信息传递的损失，减缓紧凑高效的反馈循环。
所有这些因素共同决定了我们团队采用“自下而上”的运作模式：高管不会指示“你们应该做X”，而是由我们自主判断哪些功能对客户影响最大，进而开发相应工具。高管通过评估我们对产品一线团队的影响，确保我们 真正 解决了实际问题。
守护者的复合回报
在肖恩描述的产品环境中，季度目标频繁调整，功能开发多具实验性质，速度成为终极价值。你必须在市场变动前完成交付、迭代，并迅速转向新项目。但在基础设施与开发者体验领域，上下文才是核心价值。
将工程师视为可替代资产会摧毁上下文。你或许获得新视角，却会丧失对系统实际故障机制的隐性认知。长期守护单一系统能释放复利效应，这是短期轮岗无法企及的。
其一是模式匹配带来的效率。当你在某个领域深耕数年，新需求往往并非真正“全新”。我不仅在调试代码，更在调试工具与数百支多元化工程团队的交汇点。当新团队带着“独特”问题求助时，我常能追溯历史： “2021年相机团队尝试过此方案，失败原因在此，而真正有效的架构在此” 。
但更强大的回报在于系统性创新。若每年轮换团队，你只能解决眼前可见的急性故障。然而某些问题，唯有在漫长时空中才会显露其形态。
以我近期主导的Bigtrace项目为例：这个解决方案的诞生，完全源于我坚持足够久才看清问题的全貌：
- 2023年初(观察期)：我开始注意到一种规律。谷歌各团队正收集着数TB甚至PB级的性能追踪数据，却苦于无法有效处理。工程师们编写着脆弱的定制化数据解析管道，频繁抱怨分析迭代过程何其缓慢痛苦。
- 2023年大部分时间(研究阶段)：我并未急于构建生产系统，而是在处理其他项目的同时，用近一年的时间默默进行原型开发。我向那些曾提出抱怨的工程师们收集反馈，由于建立了长期合作关系，他们给予了我坦诚而深入的意见。我由此明确了他们对用户体验、延迟和吞吐量的具体需求，并制定了满足这些需求的解决方案。
- 2023年末至2024年初(执行阶段)：我们开发并发布了Bigtrace——一款面向追踪数据的分布式大数据查询引擎。如今它每月处理超过20亿条追踪数据，已成为100多名工程师日常工作流程的关键环节。
若当初采纳“追求可替代性”的建议(即2023年转岗追逐新项目)，Bigtrace便不会诞生。
相反，我会在研究阶段离职，继任者仍会看到工程师们抱怨的同样“噪音”。但缺乏历史背景来识别缺失的拼图，我认为他们很难构建出类似Bigtrace的产品。
“拒绝”的力量
追逐“聚光灯”最具诱惑力的论点之一，是它能确保资源和高管关注。但这种关注实为双刃剑。
高曝光项目往往充满变数：高管喜好反复无常，政治博弈层出不穷，最终常陷入牺牲长期质量以换取短期生存的困境。对某些工程师而言，驾驭这种混乱充满刺激感。但对我们这些重视系统稳定性的人来说，这如同深陷陷阱。
守护者的优势在于能积累另一种资本：信任。当你用数年时间交付可靠工具后，便获得了政治资本——当聚光灯威胁到产品时，你有底气说“不”。
近期聚光灯聚焦于人工智能，每个团队都承受着整合AI的压力。我们屡次被问及： “为何不将大型语言模型集成到Perfetto？” 若只追求曝光度，答案显而易见：开发LLM封装器，向管理层演示，宣称我们“AI优先”——这将为我的职业生涯赢得轻松胜利。
但作为系统守护者，我深知Perfetto的核心价值在于精准。当内核开发者调试竞态条件时，他们需要精确的时间戳而非虚幻数据。用户信任我们所说的“X是问题根源”确实是问题所在，而非让他们耗费整周时间追查根本不存在的故障。
但切忌走极端：怀疑精神不应沦为阻挠主义。面对人工智能，我们的立场不是“永远拒绝”，而是“在确保正确实施前暂缓推进”3。
渴望聚光灯的工程师或许视此为错失良机； 我却视其为守护产品核心价值的盾牌：用户信任。
影响力的替代货币
工程师最常担忧的“聚光灯效应”是职业发展停滞。其逻辑是： 若无法在Google I/O发布炫目功能，工作未入选副总裁重点项目清单，我如何晋升为资深工程师？
诚然，你将失去“高管可见度”这枚货币。但在基础设施领域，你将获得两种同等珍贵且更具稳定性的替代货币。
影子层级
在产品部门，你常需取悦上级主管；而在基础设施部门，你需要赢得客户主管的认可。
我称之为影子层级。你无需让 自己的 副总裁理解代码细节，而需要让 其他 关键部门的资深工程师依赖你的工具。
当像Pixel团队的资深工程师对副总裁说：“没有Perfetto我们根本无法调试下一代Pixel手机”时，这句话分量十足。它会沿着汇报链向上传递，跨越总监/副总裁层级，最终传回你的上级耳中。
这种技术性背书极具说服力，因其根植于技术而非政治博弈，难以伪造。当你守护着关键系统时，晋升材料里将满载公司顶尖工程师的证言：“此人的工作成就了我们的成功”。
效用账本
当产品团队沉迷于日活用户或营收数据时，我们专注追踪工程健康的指标：
- 实用性：每修复一个工具相关漏洞，都意味着工程师认可我们的价值。这是最纯粹的实用性衡量标准。
- 关键性：当Pixel团队用Perfetto调试阻碍发布的卡顿问题，或Chrome团队用它修复内存泄漏时，我们的影响力便与他们的成功紧密相连。
- 普遍性：当技术方案能覆盖相当比例的工程师群体时，便证明你创造了一种技术“通用语”。这种现象在公司不同部门协作时尤为明显——共享的Perfetto跟踪记录成为“人人理解的参考标准”。
- 规模性：处理拍字节级数据或数十亿条跟踪记录的能力，比任何设计文档更能证明架构的弹性。
当关键性(VIP团队必备)与实用性(漏洞持续修复)相结合时，你便构建出不受管理层重组影响的晋升依据。
角色原型与主动权
资深工程师原型
提出“资深软件工程师存在多种形态”的观点者远不止我一人。威尔·拉尔森在《资深工程师》一书中，将资深工程师分为四大典型角色：
肖恩将工程师分为解决者与得力助手两类：前者作为高管意志的执行者，深入火线解决问题后便抽身离场； 我在此阐述的是架构师或技术主管：这类角色以长期负责特定领域及深耕技术场景为特征。
“运气论”的反驳
我已预见到这样的质疑：“你只是碰巧遇到了理想团队，多数人可没有这种奢侈条件。”
本文所有建议需注意两点限制： 首先，我采用的策略需要公司具备足够盈利能力来维持长期基础设施建设。这条路径在初创企业或早期成长型公司中通常不存在，它专为大型科技公司优化。
其次，运气确实会在加入优秀团队时发挥作用。从外部准确评估团队和公司文化非常困难。但尽管找到团队可能涉及运气，而能在其中坚守近十年则是我的选择。
至少就我所见，我的团队并非特例：仅在Android部门就能列举出另外五支类似团队4。虽然可能出现总监或副总裁的变动，但核心使命与工程团队始终保持稳定。
这类团队看似稀缺，并非因其不存在，而是常被忽视。它们既不提供产品发布那种快速可见的“胜利”，也不开发“炫酷功能”，因此竞争较少。若你渴望“服务数十亿用户”或期待亲友使用自己开发的成果，这里无法满足你。这就是入场券的代价。
但若你渴望构建长期系统，愿意用外部认可换取深度技术掌控权，只需掀开幕布一探究竟。
结语
科技行业总鼓吹快速行动。但另有蹊径可循——这条路以深度、耐心为杠杆，以默默筑基的静默满足为动力，让他人得以立足其上。
在大型企业里，你无需追逐聚光灯也能成就意义非凡、影响深远的职业生涯。有时最雄心勃勃的抉择，正是扎根原地、深耕细作，打造经得起时间考验的基石。耗费数年与问题领域共处，直至洞悉其本质，最终铸就Bigtrace般的永恒之作。
- 所谓产品团队，我 并非 指“前端团队”：即便身为后端工程师，你仍在参与直接服务终端用户的环节。↩︎
- 此处未尽其意，Perfetto虽为开源项目，我们确实关注外部开发者，但这绝非我们获得报酬的根本原因。从公司角度看，投入开源漏洞修复的时间属于“浪费”，但我们坚持如此，只因坚信开源使命。我在近期文章论Perfetto、开源与公司优先级中对此有更深入阐述。↩︎
- 值得一提的是，大型语言模型或许并非“将AI融入Perfetto”的最佳方案：在我看来，神经网络等“传统”机器学习技术仍蕴含巨大价值。许多跟踪分析本质上就是模式匹配。这正是我希望在未来一年深入探索的方向！↩︎
- Android内核、Android系统健康、Android运行时、Android相机HAL、Android Bionic ↩︎
本文文字及图片出自 Why I Ignore The Spotlight as a Staff Engineer
在我25多年的职业生涯中，我领悟到一个道理：若不主动掌控自己的叙事权和工作成果，他人必将据为己有——尤其在美国企业界。
我已记不清有多少才华横溢的工程师被剥夺功劳，仅仅因为某个技术能力平平却人缘极佳的同事暗中操纵，抢走了本应属于他们的风头。
你未必需要站在聚光灯下，但必须留下书面记录。无论在公司内部还是外部，都要为自己的成果和发明争取应有的认可。无需成为“领英思想领袖”，只需向行业会议投稿演讲，并寻找其他公司里懂得区分“实干者”与“空谈者”的同行。
每个组织都遵循这套规则，不仅限于美国企业。想加入校棒球队？最好讨好教练和队友，否则只能坐在板凳上记分。想进哈佛研究生院？得搞对人脉。想在机器学习领域出名？最好通过参与大量浅层项目博取关注。整个世界都是骗局，而骗子永远是赢家。
但真正有实力者是个例外。若你能击出本垒打，或以激光般的精准度和速度投球，即便你是内向的社交白痴也能进校队。或许当不了队长，但教练要的是能赢球的选手，不是舞会国王。
这不是骗局。这是人类创造、为人类存在的体系。仅此而已。金钱、成果等事物之所以有价值，是因为人们赋予它们价值。若剔除人类因素，你所做之事便毫无价值可言。生活不是带有全知计分器的电子游戏——他人本身就是计分器。
在你眼中：人们常在计分上表现拙劣，被那些无助于整体胜利的价值所分散注意力。
有时这未必是坏事。当然，某些偶然相遇建立的友谊甚至亲情，可能比赢得比赛更有价值。但行动必有后果，或许有人需要这场胜利来实现目标。
在我看来，唯一真实的分数是集体对分数的感知。不是数字，不是公式，更不是你自以为的分数。不存在可指认的外部绝对计分器，因为集体视角才是真理。
难道我不属于集体吗？我的感知何时才重要？难道多数人说了算，而我只是个随自己节奏跳舞的异类？
鉴于我国对2025年的“集体观点”，我选择退出评分体系，谢谢。
人们向来不擅长为他人评分，因为他们通常只关注自己
评分本无客观标准，正因如此人们才堪称评分专家——评分本质上就是他人赋予的价值。如同货币或股票的价值。当你领悟到这一点，生活中的诸多困扰便会大幅减轻。
若真如此极端地看待人生，反而更易陷入挫败。当你确立自身价值观后，便会发现那些价值观相悖之人并非社群伙伴，而是需要跨越的障碍。此时人生不再是团队协作，而是生存竞技。虽未必是赢家通吃，但多数人终将输多赢少。
需要集体认同的“评分体系”来避免这种局面。
这与价值观无关，而是价值本身。你所做之事是否创造了价值？当你意识到价值的唯一衡量标准在于他人如何看待你的作为时，挫败感便会大幅减轻。这反而促进合作——你必须与他人协作沟通，而非固守那种孤立无援的虚妄价值观念。
这正印证了我前文的警示：若对方认定的“价值”与你相悖，你们就成了障碍而非目标共进的团队。
若某位经理的价值观是“敷衍了事等退休”，而你却使命驱动，障碍便已形成。此时你只能绕过障碍暗中突围，核心工作却无人承担。经理惊慌失措，被迫承担更多工作，最终可能责备他人。双方不过是在遵循各自目标赋予的“价值”罢了。
我们确实需要“价值观”，复数形式。多元价值观能让单一“价值”在必要时作出妥协。于是我们从“我只想退休”转变为“好吧，我会确保那个干劲十足的人能参与更重要的项目，而我则放松一下”。也让那些“我想改变世界”的人偶尔妥协：“好吧，这个人此刻需要帮助”。这并非扼杀梦想，而是确保集体目标得以实现。
有时成就本身就是最好的证明，为行动者提供天然的营销。但这需要成就足够惊人——才能在喧嚣中脱颖而出——且必须是单一行动者的明显成果。唯有一个人能站上打击区挥动球棒。
我读的学校里，教练给喜欢的队员发嚼烟，欺负书呆子。那个运动天赋超群的黑人孩子被欺负得转学了。首发投手是个开大卡车的蠢货，天赋平平。
我假设教练是正常人，目标是打造团队赢得比赛。若他作为成年人仍沉溺于青少年心态，渴望以青少年为友，那除了远离别无他法。
但若你只是内布拉斯加州某个偏僻小镇的棒球好手，无人知晓你的存在，就永远进不了美国职棒大联盟。
这正是球探存在的意义——深入挖掘人才宝藏。
但天赋也至关重要。自学成才者能与多年训练的选手抗衡实属罕见。所以双方都有道理。
确实，但有多少跳级经理会去大型科技公司发掘正在开发内部绩效评估系统的顶尖程序员？
据我所见，跳级经理对晋升至关重要。
确实如此。在体育领域，某位球员可能成为价值数十亿美元营销活动的火花；但在开发领域则不然。企业本就试图将开发岗位商品化。
不太认同。
我举的例子是台积电/张忠谋。
> 在德州仪器25年的职业生涯(1958-1983)中，他逐步晋升为负责全球半导体业务的集团副总裁[19]。1970年代末，当德州仪器转向计算器、数字手表和家用电脑领域时，张忠谋意识到自己在半导体领域的职业生涯已陷入死胡同。
此人堪称黄金般的人才，德州仪器却弃他而去(另有说法称美国/德州仪器内部的反亚裔情绪构筑了玻璃天花板，使他永远无法成为CEO)。
他在美国的“击出全垒打”能力遭人忽视，却在中华民国/台湾地区大放异彩。无论正反两面，决定成败的并非他的能力，而是谁愿意相信他。
编辑：冒着因政治化讨论招致更多非议的风险补充：
左派普遍致力于消除的各种“主义”，实际上都在阻碍经济潜力释放——性别歧视、种族歧视尤为严重(因其影响人群基数庞大)
确实如此。若真正审视美国历史，就会发现2025年的现状本质上是对“有色人种与女性可与白人并肩工作”理念的强烈反弹——部分白人根本无法接受这种转变。“当特权成为习惯，平等便成了压迫”
所以。摧毁工会与法规，让富人垄断财富，再辅以五十年的其他手段。他们依然痛苦不堪，但至少比那边的恩里克强——那人不过是想让孩子过上更好的生活。
这 或许 是对现状的合理概括，但我怀疑过于简化了。这些企业的轨迹不仅取决于组织架构顶端的姓名。德州仪器转向消费电子而非半导体，事后看来或许愚蠢，但即便在事后也未必如此。其战略本质是试图成为苹果或英伟达而非英特尔或台积电。失败并不等于尝试本身错误。
而这一切未必与张忠谋个人有关。台积电这类企业的成功需要多重因素协同作用。张忠谋或许是其中之一，但德州仪器可能存在其他关键要素——也可能不存在。所谓“德州仪器排斥张忠谋导致这些要素缺失”的说法，我们永远无法确证。
>德州仪器转向其他商品而放弃半导体业务，事后看来或许愚蠢，但即便事后审视也未必如此
我认为即便到了90年代初，这仍堪称极其愚蠢的决策。个人电脑正蓬勃发展，他们却放弃了在需求即将暴增的领域深耕技术？虽然可能存在与学校用品相关的优渥教育合作，但他们实际上将一座金矿拱手让给了中国。
> 关于德州仪器因排斥张忠谋而未发展芯片业务的说法，真相永远无从知晓。
但我们确实掌握着极具说服力的证据——若德州仪器能提供台积电那样的成长环境，其发展轨迹本该截然不同。
这要看具体情况。观察职业冰球运动员出生月份的分布图[1]便知： 第一季度出生的球员进入职业联赛的概率是第四季度的两倍。出生月份的唯一影响在于为青少年时期多争取了0.5年的曝光机会，这不应影响球员的其他表现。而这种效应持续数十年之久。
若你在尚未成为顶尖选手时就获得初期支持，这点支持就能让你成长为更优秀的球员。
[1]: https://www.lockhartjosh.ca/2017/11/hockey-birth-month-why-i…
在美国，美国冰球协会(目前最大的青少年冰球组织)按出生年份分组。若你出生在年末，就会成为队里最年轻的球员。通常你体型较小、经验不足，除非天赋异禀，否则上场时间往往较少。这种影响从你加入首个青少年球队一直持续到高中阶段。
但将整个世界称为骗局，无异于让最糟糕的部分定义整体。尽管如此，游戏规则似乎确实偏向那些声音最大或人脉最广者。
这确实是骗局，客观事实如此。若对此浑然不觉，终将被利用。世上没有哪个地方能让你仅凭他人或体系的承诺就安然生活。
恕我直言，这观点颇具美国特色。世上仍有社会凝聚力强、信任度高的地域。并非所有地方的人都时刻伺机害你——只是在那些鼓励此类人际关系的社群中，情况并非如此。
即便在高度信任的社会，你仍不能轻信他人言辞——因为当地文化未必倡导直率表达。日本便是典型：社会凝聚力与信任度极高，但商业场合仍因问题传达方式而难以周旋。
感谢venturecruelty对“谁可能针对我”的见解。你认为选择用户名完全不反映内心想法吗？
你推荐哪个？据我所知他们大多在消费不断欺诈你的美国产品… 身为欧盟居民我也深有体会。
若这只是偶发事件，是否意味着多数情况下可以相信他人承诺？若你完成九笔交易，第十笔遭遇欺诈，难道不说明前九位交易对象都是诚信可靠的？
哈哈不，这种可能性存在是因为许多人根本穷得连交易资格都没有——他们大多生活在无名系统中，早已被无名企业预先欺骗
我认为在团队运动中，球员的人气并非完全无关紧要。更衣室凝聚力很重要。
恕我直言，你说的每个字都是错的。迈克尔·乔丹过去是、现在仍是每个队友都讨厌的混蛋——史上最伟大的球员。考上哈佛和人气毫无关系。或许靠父母关系进的校友，或者纯粹是学业出色——我认识好几个哈佛毕业生，受欢迎程度跟华盛顿将军队球员差不多。至于机器学习领域，最受追捧的都是那些年薪七八位数却无人知晓的家伙(我只通过同事听说过其中一位)。
“恕我直言，你说的每个字都错了。迈克尔·乔丹过去是、现在仍是每个队友都恨的最大混蛋——史上最伟大的球员。”布朗尼·詹姆斯在NBA打球… … .. . 迈克尔·乔丹棒球打得糟糕透顶，却获得了参加MLB选秀的真正机会。
“最受追捧的恰恰是那些年薪七八位数却无人知晓的球员”
你一句之内就自相矛盾…我直接共事过你所指的那类人，其中多数都是骗子。
“我认识好几个哈佛毕业生，人气跟华盛顿将军队球员差不多”
你没看懂我的意思。关键在于环境的动态性。学术圈和任何地方一样，融入群体同样重要。
有时确实如此，但我发现才能和技能终究会得到回报。最理想的情况是两者兼备。
当才能易于定义和衡量时。我对运动员的敬重远胜于科技领袖。
这正是我试图摆脱企业环境职业生涯的主要原因之一。政治斗争太过泛滥。我多希望工作只是完成任务回家，凭成果获得回报，但现实中却充斥着大量自我推销(即营销)成分。既然如此，我不如去做能自主掌控的事业。既然必须费心推销自己的成果，不如尝试摆脱上司束缚。我始终认为，作为雇员接受固定薪酬的意义正在于不必操心这些事——这本是公平的交易。
社会对晋升管理层的职业发展过于强调。我认识太多程序员，他们只想解决最棘手的技术难题，做出值得骄傲的优秀作品，然后回家陪伴家人。他们最渴望的是稳定。
确实存在极少数软件公司，程序员的工作内容 完全符合 这种理想状态。薪资虽不及FAANG巨头及硅谷/洛杉矶/纽约初创企业，但工作与生活平衡极佳，稳定性极佳，最重要的是能专注于创造卓越成果。这里不追求季度目标，而是致力于长期培育(或说耕耘)软件项目。工程师们通过深度专注的功能开发与问题解决获得巨大成长。
我在这样的公司工作了15年。对我而言的缺点是薪资较低、没有股权激励，也无法获得广泛的行业经验。最终我选择了离开，如今收入大幅提升，但确实怀念那段时光。
最令人唏嘘的是，过去在某些巨头企业也能实现这种状态。“资深工程师”(仅次于高级工程师)普遍被视为“我已达到职业高度，现只愿钻研有趣问题”的象征——除生活成本调整外基本不会涨薪，但能专注工作后回家享受生活。这种状态至今仍可维持，但频繁的裁员让整个处境增添了不确定性。如今你不得不比以往更重视自我推销和“展现工作成果”这些职场操作。
他们还给生活成本涨幅吗？我在FAANG任职时，同岗位涨薪甚至跟不上通胀。
说得对，涨幅常低于通胀，根本是象征性加薪
谷歌允许员工永久停留在L4级别，Meta则在L5级别终止晋升通道。
虽然期望值可能依然很高，但正如楼主所言，这些公司并不期待所有人超越“基本独立工程师”的水平。对于有志于此的人，公司提供了完整的非管理路径，可晋升至总监级别的IC职位。我观察到小公司更倾向将管理岗位视为晋升而非横向调动(每当听到“晋升为经理”总让我不寒而栗)
这取决于团队——管理职责的范围可能远超资深工程师，具体取决于该角色的期望。随着时间推移，管理者对技术成果拥有更广泛的责任，更不用说培养团队的额外职责。管理者承担着资深工程师的所有责任外加更多任务。从这个角度看，管理岗位对我而言是明确的晋升。但若仅比较管理岗与普通工程师，情况可能不同。
管理岗位不被视为晋升，并不意味着管理者通常不高于其下属(我曾有过与管理者同级甚至更高的经历)。这意味着从技术岗位转入管理岗位本身绝非晋升(例如谷歌/Meta体系中始终是L6→M1)，且不会带来薪酬差异。
可惜2025年不会实现。这类公司最先冻结招聘，有些甚至可能撑不过这场风暴。
虽然有这样的保障很理想，但我的行业本就不以稳定著称。
最近解决了哪些有趣的技术难题？
和这里多数开发者一样，在大型团队负责核心产品领域的前端功能交付 🙂
要具体阐述实际解决的问题并清晰表达，需要提供特定背景，而我在此不便透露。
若身处平台/基础设施领域或担任高级工程师以上职位(我过去都经历过且非常享受)，用更具普适性的细节描述“有趣的解决问题”会容易得多——但目前我并非处于这些岗位。
大多数人都受保密协议约束
我敢肯定没人会在HN上追查保密协议违规行为，除非发帖者蠢到具体透露解决问题的具体工作场所和时间。若需要调查才能拼凑出最基本细节，我认为这本就在多数保密协议的条款范围内。
我认为没有股权未必比获得股权后破产更糟糕 😀
当然存在。甚至有专有名词形容这种情况。按定义来说，你永远不会听说这些案例。
https://www.hanselman.com/blog/dark-matter-developers-the-un…
谷歌的终极职级仅比应届生高一级，且设有完整的非管理类工程师平行晋升通道，我认为他们并未强迫员工过早进入管理岗位。
这恰恰是程序员选择编程的初衷。令人费解的是，技术职业却将多数人推向管理轨道——人们苦读计算机科学多年自有其道理。我为何要放弃这些技术技能？
你的意思是就算人人拼命努力，也无法人人当CEO？ 🙁
谁都能当CEO，只要创办公司就行。
所以我们不需要教师或清洁工？人人都能靠努力发大财？
如果人人都想当CEO当然可以。但很多人并不想(我肯定不想)，而想当的人中多数会失败。因为“努力工作”是相对的。
更别提天生不平等的出身优势了。
我不明白你从我评论里怎么得出这个结论。CEO是个容易获得的头衔，这才是我的核心观点。
那当你求职时遇到行为面试题，只能回答“我十年都在看板上拖拽Jira工单”怎么办？
没错。面试官都想听你主导过跨部门项目，并具体说明其商业价值。
问题在于——至少我认为——你可能完全不了解经营企业的现实要求。其中涉及更多政治博弈、更残酷的竞争、海量必须遵守的法规(违者可能面临后续处罚)、法律风险等等。
我理解，但真正的问题在于教育体系本身。若你所言属实，意味着专家制度已名存实亡，然而几乎所有大学仍在培养专家型人才。要么行业彻底摒弃学历主义，要么学校应调整培养模式——除学术研究类专业外，多数学位课程应优先传授商业知识，技术知识次之。
此言部分正确，部分有误。
这个“体系”需要以下要素：
不了解体系运作、埋头实干、视体系为平庸、拒绝玩弄规则的人。
少些玩弄规则的人——他们不劳而获，坐享其成。
问题在于，一旦玩弄规则者过多，整个体系就会崩溃。
我弟弟正在攻读经济学，他说人人都该掌握基础经济知识——理解市场运作机制能极大助力求职和职场适应。或许商业知识更实用，但我个人偏爱经济学的实证精神 🙂 你关于“需洞悉企业思维与运作方式”的观点确实切中要害。
公平地说，这并非大企业独有的问题。我在学术界也见过类似现象，有些人就是深谙“游戏规则”且玩得炉火纯青。
这很大程度上取决于所在机构的文化氛围，甚至同一组织内不同团队也可能存在差异。
有些人似乎故意对规则视而不见。当面对现实时，他们转身逃避，抱怨规则存在，表现得像被欺负的初中生。
你不必热衷于认同这套规则。你可以像学习围棋或Rust语言那样掌握它。你可以拒绝主动参与，但至少要足够清醒，避免被它伤害。
例如：找出最省力的方式，让规则玩家相信你的工作很重要。
对此我存疑，尤其在本文语境下。这种模式确实适用于那些靠一次爆红项目就能奠定职业生涯的闪光案例。但多数职业道路并非如此，而本文恰恰在讨论非此类路径的从业者。
我发现信任是企业环境中的货币，或许是最重要的货币。而信任需要时间积累。如果你默默付出确保项目成功却不居功，很可能有人会抢功，甚至将其写进自己的晋升材料。但若你长期参与众多成功项目，领导层很可能注意到其中的共同因素正是 你 。在此过程中，你将积累良好声誉与人脉网络，即便领导层更迭，仍会有众多伙伴愿与你共事。晋升初期或许缓慢，但终将迎头赶上——毕竟你无需承受项目失败或角色更迭带来的重置风险。
> 但若你长期参与足够多的成功项目，管理层很可能注意到你才是贯穿其中的关键因素。
此规律仅在管理层平均任期超过数年时成立。
如你所言，晋升确实会更缓慢。相比善于自我推销者，你的职业天花板也可能更低。
我亲身经历过好几次！
汉明在其著作《科学与工程的艺术》中也提倡这种做法。
但该书最后一次修订版是1994年，作者当时的立场是基于在贝尔实验室工作大半生的经历。如今我们已不复拥有这样的环境。
若能成为不可替代的开发者实属难得。我认为策略之一是主动争取曝光，管理他人对你工作的认知。多数时候你无法选择工作内容，但可确保成果可见且实用。
正如作者所言——这也是我追求的目标——打造受人珍视且依赖的优质工具与库。
意识到外表比实力更重要——无论在职业、政治、约会还是商业领域——确实令人沮丧。务实的做法是坚持实力，但也不可忽视形象。
然而我内心的理想主义者对此深恶痛绝。本应是品质胜过宣传，但在现实中却鲜少如此。
究其根源在于时间精力是有限资源，而精准衡量实质价值成本高昂。衡量表象成本低得多，或许能成为可接受的替代方案——尽管往往名不副实。
我个人毫不在意。付钱给我，然后给我滚远点。在这颗美丽的蓝色星球上，我们顶多活上八十年光阴——若运气极佳的话。我绝不愿浪费哪怕一秒钟去玩那些愚蠢的游戏，只为在某个僵化的经济体系里出人头地，而这个体系直到最近才崭露头角。
所以我将继续竭尽全力奋斗，同时把时间投入真正重要的事物：音乐、艺术、为自己和朋友烹制美食、我的爱好、我的家人、我的社区。美国企业界本就缺乏快乐与意义。也许这让我显得愚蠢，但我不在乎。我宁愿活得真实。
在我看来，你已基本为人生现阶段打造出萨希尔·布鲁姆所说的“人生剃刀”
不必过度自我推销，但必须为自己的作品发声
我向来预料到世道如此残酷，人们会不择手段窃取他人功劳。
但现实远比想象复杂。许多好点子若无人恰当推介就会夭折——即若无人能让团队/组织/公司理解并认同其解决关键问题的价值。
成熟的商业或技术领域里，真正新颖的创意本就寥寥无几。每当我自以为提出创新构想时，翻查公司内部文档总会发现——五年前某份被遗忘的设计文档里，早已有人提及相同观点。
我逐渐意识到，好点子产生实际影响的难点和瓶颈，既不在于点子本身或执行过程，而在于如何拨动正确琴弦为其开辟空间并获得认可。在小范围内，比如你自己的团队或职责领域，这倒不是必需的，你可以直接动手实现，让成果说话。但若不能正确牵线搭桥，这个创意对整个公司的影响就会受到限制。
有些人鄙视这种想法，若你也是其中之一，那么大公司可能不适合你。但我见过多数“优秀工程师被剥夺功劳”的案例，都是因为当事人未能意识到并履行这份工作中必不可少的部分。若你让某个创意停滞不前转而投入新项目，随后他人介入并使其获得更广泛认可，那么：1. 你通常仍能获得部分认可，实现双赢局面；2. 对方并非真正窃取功劳——因为若无人接手，该创意本会胎死腹中，你同样无法获得认可。
在我看来，这正是1对1会议的核心价值所在。
现实中，人们常因“先发制人”和“高调宣扬”而抢占功劳。例如某人指出团队正在处理的问题领域，高调批判现有方案缺陷并宣称自己能解决——即便该方案本就存在，且首创者尚未完成工作。即便最终由他人完成任务，该成员仍能潜移默化地将成功归功于自己的思想领导力/方法论。
优秀的管理者/领导团队会建立机制遏制此类策略，但这要求他们与每位成员沟通——倾听未言明的反馈并审视硬性成果。否则团队很快就会沦为只会空谈问题、幻想解决方案的空谈者。
本不该如此。能力本应是衡量标准。但现实就是如此。无论你的数据表现优劣，只要博伯喜欢你，你就稳了。
继续打磨你的软技能吧。若你长着张只有母亲才会爱的脸，那就去当作家……但务必让你的声音传出去。
你完全可以掌控话语权，同时 不 成为聚光灯下的焦点。
归根结底，任何组织里真正重要的利益相关者屈指可数。只要能向直属主管、跨级主管以及产品、销售、客户成功和领导层的关键成员有效推广你和团队的项目——你的地位就稳如泰山。
事实上，多数情况下我认为过度曝光反而弊大于利——它只会增加他人将你视为预算或职责竞争者的风险。
只要你始终与企业年度目标保持一致，并能向相关利益相关者群体有效传达，便无需刻意追求聚光灯效应。
这篇文章非常精彩。别被“反政治”或“慢即是美”的论调迷惑——它描述的是一种政治运作模式，若操作不当其影响同样如产品开发般善变。基础设施与开发者体验团队的运作本质截然不同，若契合你的性格特质，这会是条绝佳的职业路径。
背景说明：我在Slack担任基础设施团队产品经理长达五年，直到第四年才了解Slack的产品发布流程。此前所有工作都聚焦于内部系统——K8s/服务网格及数据库基础设施。
关键洞见在于客户成功与影子管理机制。每位成功工程师(包括我自身)的成就，都源于精准把握产品工程师需求并高效交付。而“影子层级”反馈机制正是晋升成败的关键。优化此机制极具挑战性——你必须主动获取反馈、判断解决方案的有效性，并以足以影响产品组织的时效完成交付。
若你愿意为这种内部成功进行优化，终将获得回报——无论是在职业发展还是组织稳定性方面。我不同意这种机制仅存在于科技巨头——在合适的团队和管理者带领下，百人规模的公司同样能形成真实而强大的文化。
但别以为这是无视业务核心的魔法捷径。它只是管理协调与政治博弈的另一种方式——或许更易接受，而这种博弈本就是任何企业成长的必经之路。
我在中型企业也见过同样的动态
这篇文章阐述精辟，作者对产品工程组织与基础设施工程组织评估差异的洞察尤为深刻。从他仅用不到八年时间就完成硕士学位并晋升谷歌L7级别的经历可见其扎实的技术功底，而这种成就显然离不开驾驭大型组织政治的能力。
不过我必须指出，文中呈现的逻辑仍存在相当程度的天真。归根结底，这些概括与合理化解释仅基于一家规模庞大的企业，且隐含地依赖于众多副总裁和高管的视角与优先级——他们的思维模式可能与你在基础设施一线的认知存在偏差。谷歌确实秉持工程驱动的文化，因此作者的观点或许不无道理，但这也仅限于特定时空背景。谷歌享有行业最强势且最盈利的市场地位，这种优势早在作者入职前就已确立，因此其基础设施团队享有多数企业难以企及的舒适度与庇护环境。趁着顺境多做实功课，但务必时刻警惕：领导层的态度和优先级可能因市场或投资者压力骤变。届时你必须做好准备，在更受审视的新环境中重新证明自身价值，或(遭遇裁员时)转战新公司。
我深知公司赋予我的特权与所处时代的机遇。我在文中多次强调，这绝非“通用的成功指南”，在其他公司或团队中可能需要截然不同的策略与方法。
我撰写此文的初衷，是看到Sean近期在HN的成功案例后，发现人们过度倾向于“必须不断跳槽追逐高管关注”的观点。我只想通过个人经历证明：某些岗位上完全可以开辟不同路径，同时保持进取心并取得(某种定义下的)成功。
你读完全文了吗？作者在结尾已回应这些质疑。他们并非天真。
这确实是大型企业的梦想。我曾供职的某家科技巨头就存在典型陷阱——不知如何评估高级工程师。考核最终沦为人气竞赛，评分标准竟是“对技术社群的影响力”之类的无稽之谈。
默默创造价值，助力优秀人才成长，这才是真正的价值所在。
关于你提到的巨头公司、楼主及其讨论的帖子，核心问题在于它们都与金钱脱节。
这里存在两个极端：
1. 风险投资路线：一旦淘到金矿，便永远不必面对投资回报率的现实，满口都是聚光灯、影响力与价值，却从不谈论真金白银。
2. MBA路线，连刷牙都要成本效益分析，而分析本身往往耗费数倍于行动的成本，最终导致技术债务末日来临前寸步难行。
现实是：若你仍在靠抽象概念赚钱却无法说明收入成本，那你大概还处于好日子。
读来令人痛心，却不得不承认。一针见血。
这种两极描述完全符合我的经验
那些重要却不显眼的核心工作，往往更容易被他人彻底搞砸。
“噢，这东西看起来稳当又无趣，根本不需要六人团队。”
转眼间，整个体系便分崩离析，摧毁了所有建立在其稳定性之上的事物。
这本质上是系统管理员的两难困境。
一切运转正常时：“我们付你薪水是干什么的？”
系统出故障时：“我们付你薪水是干什么的？”
没错，几年前我搭建的系统曾支撑着当时的新产品，如今却为公司创造可观收益。这套系统可靠得令人震惊——公司里鲜有人知晓它的存在，而知晓者更将其稳定性视为理所当然。它既不涉及成本问题也不引发可靠性危机，因此人们根本无需意识到这套小软件有多么出色——正是因为它默默运转着，默默处理着连接故障和数据库维护等事务，从不引发实际问题或需要维护，才让人们无需为此操心。
这多少有些悲剧性的讽刺：工作做得越出色，越容易被忽视。(:
请记录使用该软件的项目，同时统计API调用次数、故障恢复次数、运行时长等指标，整理成宣传资料包
感谢建议，我真心感激！
或许你该安排“计划停机”——当支撑系统进行“维护”时，他们自然会注意到！[半开玩笑…虽然可能不现实，但总比在极端时间压力下救火强]
遗憾的是，在这个行业里，我们正被那些不再精通如何构建优质软件系统的管理者所领导。他们无法评估代码贡献的价值，于是转而衡量参与度和人气。
作为工程师，你面临两难抉择：要么专注编写扎实代码推动项目进展，要么专注向领导层推销自己。
当你写出扎实代码时，推销自己就容易得多
若你写不出扎实代码，那么比起那些写得好的同行，更擅长推销自己就显得尤为重要。
深表赞同(但由于HN糟糕的移动端体验，我不得不给出负面评价，抱歉！)
前世我总抱怨：人们只在我搞砸后修复问题时才夸我。明明月复一月出色完成工作，听到的全是抱怨；可一旦“修复”重大问题，瞬间就成了英雄。
我领悟到：建立有效的组织体系中，最难的部分在于设计合理的激励机制。
在早期创业公司时，我曾因处理突发危机获得业务部门赞誉。当时我强调要建立这样的文化：工程团队应因让系统稳定运行而受奖，而非因救火而得功。
初创期的美好之处在于，此时最容易将工程文化导入正轨。一旦开始招聘，新成员要么强化你正在建立的文化要素，要么带来不良文化。
(我目前的认知是：若发现企业文化被雇佣兵式的前FAANG精英小团体或一群表演式冲刺戏剧的占位者所腐蚀，你必须彻底清除癌细胞扩散的每个角落，否则就永远困在糟糕文化里。)
> (我目前的理解是，若发现企业文化被雇佣兵式的前FAANG精英小团体或一群表演式冲刺剧场的占位者腐蚀，你必须彻底清除癌细胞扩散的每个角落，否则就永远困在烂文化里。)
你描述的正是我上份工作的写照。它从我职业生涯中最高效(我们真他妈能交付——高质量成果，通常一次到位)、最具活力且最有趣的工作场所，沦为新任副总裁踞坐每个团队的冲刺计划会、回顾会和站立会，只要我们偏离正统Scrum框架半点就会插话干预的噩梦。工程团队一年内流失率高达95%，只剩最菜的员工留下来——毕竟他们不懂该跳槽。工作效率停滞，技术债务膨胀，但产品经理们乐坏了，毕竟他们也能全程插手每个环节。
工作效率也降到龟速。后来私募股权公司趁虚而入，局面更糟了…
深表同情。
这听起来像是自上而下或中层推动的文化变革(当公司试图建立层级结构并引入外部人才时，这种情况很容易发生)。
另一个风险是自下而上的文化渗透。即使现有领导层保持不变，但当你开始招聘带着自身文化背景的个体贡献者时，若未能培育理想的企业文化，就会导致问题。
我认为初创企业面临的隐患在于：当公司扩张时，早期工程领导层若未能获得CEO的尊重与认可。即便早期工程团队建立了卓越的工作体系和文化，但若CEO将其视为可随意替换的消耗品，认为需要转变模式，那么CEO很可能迅速耗尽企业积累的全部优势。
公司由创意型创始人(非技术背景)创立，首位雇员是技术型CTO。CTO奠定了卓越的初始工程文化。在我看来，创始人初期别无选择只能顺从工程团队，因为没有他们公司就无法生存。然而当公司开始盈利后，CEO施加的压力和干预日益加剧，最终导致CTO不堪其扰离职。CEO本人并非恶劣之辈，只是难以应对反对意见(事后我与他交流时，他也承认自己当时处理不当——毕竟整个事件发生时他才二十出头)。
CTO职位始终空缺，而产品负责人竟被提拔为工程副总裁——这绝非杜撰。公司引入外部工程总监负责实施业务指标、追踪机制及流程管理等事务，所有工作均向这位产品副总裁汇报。技术部门的平衡机制就此瓦解，最高层的技术倡导者仅剩团队负责人。这位工程副总裁并非心怀不轨，但无论出于能力还是意愿，他都无法阻挡任何阻碍业务发展的决策，更无法传达适时退一步的战略意义。
不过财务上我们还算过得去。公司最终被收购(虽不足以让我退休，但45岁的我基本无需再为退休储蓄，您明白我的意思吧)，我们也由此转场。但开发节奏的放缓导致其他新创意直到被私募股权公司吞并时才初见成效。我个人认为，若当时维持原状或进行更积极的变革(企业成长确实需要变革)，我们本可以取得更大成功。
感谢您深入的观察与见解，这听起来非常真实。很高兴您最终在财务上还算顺利。
能点击显示的撤销点赞按钮吗？
点击“撤销点赞”按钮即可取消负面评价。
原来可以对投稿点赞？
当你的声望值足够高时，确实可以。
只要默默创作能带来回报当然可以。但若靠被高层认可就能拿更高薪水，我也会选择博眼球。毕竟人们工作是为了养活自己和家人，考虑到科技巨头的道德缺失，我觉得任何作品都无法改善世界。所以没错，选择博眼球和少干活才是正道。
> 人们终究要为生计奔波，况且科技巨头道德败坏，我认为你所做的工作根本无法改善世界。
这说法有点夸张。我的家人就受益于无障碍功能改进、语言翻译、视频通话、导航辅助等技术。
这些功能确实不错——前提是数据不会被科技巨头收集贩卖。
这篇文章让我深有共鸣——从业25余年，直到最近这份工作前，我通常每两年就跳槽一次。
如今在现任公司已进入第四年，过去三年带领团队构建企业内部平台——这简直是梦想中的职位：管理层基本放手，战略自上而下制定，但所有决策权都在我们团队手中。虽然起步缓慢，但如今已初见成效：多个团队开始使用我们的平台，推动真实需求落地，而非少数高管凭空想象的需求。
这让我们获得了所有“客户”的持续好评——他们原本根本无法考虑自主构建内容交付管道，而我们正解决着他们的实际痛点。抛开政治因素不谈，正是这份成就感让我每天充满干劲。
这种自下而上的推动力虽罕见，但一旦实现便充满活力
作为在同一团队深耕多年的基础设施与工具工程师：深有同感。
偶尔确实能摘取低垂的果实，赢得令全体工程师赞叹的耀眼胜利；但多数时候，这是份节奏从容、专业而充实的差事，让你在养家育子的同时保持清醒头脑。
深表赞同。这也正是我个人更倾向于从事基础设施而非产品团队工作的原因。这里能让你远离管理层或产品经理的随机决策干扰，专注追求技术卓越。我完全不想参与那些“产品发布可见的胜利”。我很庆幸目前供职于一家成立三十余年的中型企业(员工规模千至万级)，日常工作是默默优化其他团队的基础设施。
我绝非批评作者或其观点。但他未充分强调的是：作为资深工程师，他或许能无视聚光灯，但这恰恰源于他 正是 资深软件工程师的身份。
2018至2020年我在初创公司任职时，作为第二位技术员工被新任CTO招入。这位CTO当时正从外部咨询机构引入技术领导力——该机构所有长期开发人员都位于印度。
他们总在争抢聚光灯以保住饭碗。而我无需如此——我已赢得创始人、CTO等核心团队的信任，更不必担心因关键人物不知晓我的贡献而被裁员。
我并非为晋升而战，随着公司发展，我早已主导着所有重大跨部门技术项目。
另一方面，2020年我以L5级别(专业服务咨询而非软件开发工程师)进入科技巨头时，第一次目睹了职场晋升中政治博弈的程度。我个人并不在意这些。从入职第一天起，我的目标就是赚钱，四年后离开。当时我已46岁，清楚自己不打算长期留任。
但我亲眼目睹了自己指导过的优秀实习生毕业后重返公司时遭遇的困境。由于主管完全忽视他们[1]，我不得不主动为他们创造曝光机会。即便如此，他们仍需跨部门调动才能获得晋升通道。
如今站在另一端，我再次见证了这种现象。若要在现任公司——那家以职员身份招揽我的企业——经历层层关卡博取晋升，我实在厌恶这种权谋游戏。
但若为晋升，我仍会与最优秀者一同追逐聚光灯。
所幸我无需刻意追逐认可——重要人物早已知晓我的价值。我的项目自然赋予我曝光度，无需刻意争取。
[1] 所有初级员工都向独立经理汇报，并被外派至各团队。
> 但他之所以能这样做，是因为身为普通软件工程师。
我完全不同意这种说法。这正是我在谷歌整个职业生涯的工作模式——从应届生L3入职至今始终如此。回避聚光灯并非“不被他人关注”，而是“不追逐高管关注的项目”。
每次参与项目时，我都会积极确保工程师知晓项目进展——尤其当我认为项目对他们有价值时。但这与主动询问高管“当前最高优先级任务是什么”并投入其中截然不同。
那在你的晋升材料里会呈现什么效果？
你会选择开发无人问津的员工绩效追踪系统，还是参与谷歌广告相关项目？你会建议应届生选择哪个方向？
这话听起来很愤世嫉俗。但我从未刻意在大科技公司谋求晋升，这从来不是我的目标。我只是目睹了他人从L4(入门级)→L5、L6→L7的晋升过程中挣扎的模样。不知为何，L5→L6似乎反而更容易些。
就我个人职业轨迹而言，这种策略效果相当不错！欢迎从我的简历(见个人主页)自行判断。
我觉得你混淆了“高管关注”与“重要项目”的概念：这两者完全 不是 一回事。
有道理。所以如果你说“参与重要项目”是关键杠杆，我们完全认同。
只要把重要项目写进晋升材料并清晰阐述，你就稳操胜券。对晋升委员会而言，这远比“高管关注”重要得多。
但千万别成为那个埋头开发内部计分追踪系统的人——这种系统一年顶多被人想起一次
深有同感。我在基础设施团队工作数十年，经历过80人到80,000人的公司规模，但参与的项目中从未出现过项目经理。
编辑：需说明，这并非必然抱怨，尽管某些情况下项目经理确实能提供帮助。我对项目管理团队的主要顾虑在于：他们常将我的项目视为实现其目标项目成功所需的必要牺牲品。结果就是承受着专业管理层的训斥与要求，却得不到任何实质协助。
这里有个未被明确提及但在我看来符合叙事逻辑的观察：
若你筹集到足够资金(无论是社会资本还是金融资本)支撑三年运营，那么你就能坚持三年。如果两年后投资开始回报，你完全可以按原计划推进——只要第三年能见效，没人会在意你前两年如何使用资金。
真正的风险在于判断失误。
还存在另一种风险：你坚持运营两年，避免了可能在第三或第四年冲击公司的重大危机。但正因危机未曾发生，无人知晓你为团队挽回了多少损失，因此耗尽的资金无法全部回笼。
我任职过的每家公司都会定期表彰那些为赶工发布而加班的人(我在嵌入式系统领域工作，升级往往意味着要派人带着USB设备飞往无信号的偏远地区——因此无漏洞发布至关重要，因为升级成本高昂)。每次看到这种表彰，我都不禁想到：如果获奖者半年前就做好本职工作，根本不会出现这些漏洞。
看来唯有具有远见的管理层，才能真正认识到那些被避免的灾难所蕴含的价值。
谁更有价值？是森林大火发生前数年默默清理灌木丛和地面燃料的人，还是火灾发生后动用大量设备和人力扑灭火势的人？后者往往获得赞誉，前者却默默无闻。
如果一家公司缺乏这样的远见卓识的领导者，那么人们不禁要质疑：这样的公司究竟还有多少未来？
> 或许唯有具有远见的管理层，才能认清那些被预防的灾难所蕴含的价值。
我认为此处应将“远见卓识”替换为“能力出众”。
这个行业讨论“英雄式开发者”的弊端已有数十年之久，或许从ENIAC时代就已开始。历经数十年，本应让管理层对此有所领悟。
若将例子从清理灌木改为垃圾清运，道理就很清晰了：该赞扬垃圾清运工还是彻夜治疗感染的医生？两者都该。真正该被解雇的是开除清洁工的管理层。
管理层在理论上明白这个道理。但他们同样清楚奖项和产品交付的价值——这两者可能相互冲突。他们不知道如何化解这种矛盾。
人人都说自己手头的工作至关重要。谁才是对的？
若等到最后一刻才解决真正的问题，反而能以更少投入完成更多工作——毕竟提前修复的许多问题最终证明根本无需处理。
确实存在风险，但在极限情况下这种做法有其合理性。
“谁对”并非关键问题(并非否定你的观点——某些情境下确实正确，但不适用于当前讨论)。本案中，发布所需功能已提前规划并获管理层批准——按定义而言，完成功能才是正确选择(即便最终客户不需要，公司已作出承诺)。然而总会有几个本该早早解决的缺陷，却在最后关头成为阻碍发布的致命问题。
具体细节记不清了，但当时有个缺陷导致大批用户无法登录应用。
引发缺陷的工程师最终加班修复了问题。尽管问题本就源于他，管理层却把他当英雄般对待。(别担心，我们都清楚这并非 仅 他一人之过。整个系统都出了问题，他本不会因此受到严厉指责。)
自那以后，我们常开玩笑说故意制造漏洞，好让大家都享受同样待遇。
这情节简直莎士比亚范儿。
> 风险源于判断失误。
这确实是高风险高回报的策略，但若你深耕领域多年积累认知，且在开发前通过客户调研做好尽职调查，就能大幅降低风险。
当然风险永远无法归零，过去的成功确实也离不开运气成分。
能独享建造大教堂的自由，正是我的梦想。这听起来很美妙。
唯有当你的大教堂在无人问津时仍创造足够价值，才能获得这份自由。这篇帖子讨论的是工具团队——只要工具正常运作，且无人兜售“更便宜的万能工具”，管理层便不会干涉，你就能专注工作。但若工具开始给工程师制造麻烦，导致他们向管理层投诉，你就麻烦了。若有人带着“更便宜的万能工具”出现，你同样陷入困境(这种工具未必更便宜/更好，关键在于他们能说服管理层相信其价值——而你未能成功捍卫自己的工具)
编辑补充：还有一重风险：你出色完成工作，管理层却认为你无所事事，于是将你淘汰(结果三个月后系统崩溃，又得重新组建团队)
谷歌对内部工具的环境相当特殊。许多公司会开发工具，随后却因其不属于公司核心优先事项而削减资金和工程师支持。
这往往意味着开发工具要付出代价。人们会不断找你求助，因为别无选择。
优先事项之所以成为优先事项，是因为有人为之奋力争取。
你可以通过大力自我推销来争取，但更有效的方式是持续联络真正有影响力的利益相关者(你的直属经理、间接经理、项目经理、项目经理的上司，以及1-2位关联的高管)。
坦白说，后者才是常态且更轻松——因为这能确保他人为你争取资源。
不，优先事项往往取决于CEO当下认为什么最重要。
人们必须保持开放心态接受说服。若这能成为常态固然理想，但显然并非总是如此。
> 不，优先事项往往取决于CEO当下认为什么最重要…
事实并非如此——我这么说，是因为我既向过CEO的下属汇报过，现在也有CEO向我“汇报”。
多数情况下，高管团队主要依赖中高层管理人员(如副总裁/高级副总裁)作为决策过滤器，而这些管理层又依赖中层管理人员(工程总监、工程经理、首席/高级工程师及独立产品经理)。若身为IC工程师且 真正 希望推动关切事项成为优先级，你需要：
1. 说服直属经理(通常是EM)、跳级经理(通常是工程总监)及产品经理为你争取资源。
2. 思考如何证明工程提案能切实提升ARR(年度经常性收入)或降低COGS(产品成本)。
3. 围绕提案如何契合OKR(目标与关键结果)构建论证——OKR刻意设计为开放式框架，正是为了充当软性筛选机制。
> 人们必须保持开放心态接受说服…
没错，但你必须用对方能理解的语言说服他们。要洞悉每个人的激励机制，并阐明你的提案如何契合这些激励点。
————
Reddit上泛滥的习得性无助心态，对任何希望长期发展职业生涯的人都适得其反。
你曾为被逮捕过的CEO工作过吗？
你的经历不同只是说明经历不同。我并非宣称这是常态，但领导者本就形形色色。作为员工你无法改变领导层。
> 你是否曾为被捕的CEO工作过
没有，但大多数IC和HN用户也未曾经历过。
> 作为员工你无法改变领导层
确实如此，但在 多数 组织中你仍可真诚尝试——毕竟绝大多数人 并不 身处这类极端案例的组织。
整场对话都暴露了你极度不愿承认糟糕领导力确实存在的事实。
糟糕领导力确实存在且相当普遍，但若将此视为常态便是逃避责任——这种心态对任何行业从业者都极为有害，往往沦为借口。
若你既不努力改善处境(比如在内部建立人脉，或尝试离开糟糕的雇主)，坦白说我毫无敬意。
但这种做法也有弊端。
若你的团队在高层眼中不具战略价值，经济下行时就会首当其冲被裁撤。
但若你身处关键岗位——比如负责重要却乏味的基础设施——那便是纯粹的下行风险，毫无上行空间。系统运转正常时，他们视若无睹；一旦出错，你便背负所有指责成为众矢之的。
如同所有商业/职业建议，世上没有万能解药，唯有权衡取舍。
> 守护精神——长期坚守系统——能释放短期轮换无法企及的复合回报。
这不仅适用于开发工具，我认为所有项目和产品皆然。
我们行业许多领域本质上都在反其道而行，这已成为重大问题。
你不必身处谷歌或Zooogle就能目睹这些现象，甚至不必是工程师。
人终究是人。
静默影响力的长远布局：语境积累、信任构建与系统思维
这完全契合我在另一家大型企业担任基础设施首席工程师时的经历。我始终致力于产出有价值的技术成果，并习惯将功劳让给团队成员——即便他们实现的正是我的构想。只要主管知晓核心创意源于我，一切便水到渠成。
当然，最终你终究会成为焦点。但凭借知识声誉与技术实力赢得关注，远比公关式自我推销来得坦然。
这种模式在领导层更迭前都有效。
>> 与其听高管说“你们该做X”，我们更倾向于自主判断哪些功能对客户影响最大，然后着手开发这些特性和工具
这能出什么问题？
你什么意思？引用的内容正是我一贯的策略。
我不需要也不愿被自上而下地指派任务，更倾向于自主思考并向上提议。高管们欣赏这种模式——它减轻了他们的工作负担；用户获得了真正想要的功能；而我得以专注于认为重要的事情。
我漏掉了什么导致这个策略不可行？
我认为这是最高效的方法。决策 应当 在组织架构中尽可能低的层级完成。
但这基于一个重要前提：你必须充分了解高层决策。如果公司拥有良好的沟通文化，或者你在公司待得足够久以至于认识各个部门的人，那么问题应该不大。
若你的提案与领导层愿景或他们希望发展的产品方向不符…
那你也会将此纳入考量？并愿意根据反馈调整方向？
根据我的经验(我为网络安全团队开发工具)：这正是为何不应只提单一方案。我们每年通常启动一个新项目，会提出多种实施方案。领导层要求我们探索2-3种方案，我们带着数据反馈并推荐首选方案。经过两小时技术会议后，领导层批准方案并提出微调(有时甚至要求修改数据库设计以“贴近”用户体验…)
这种情况尚可接受——但必须以公司认可的方式确保正确性。当然，这绝不能损害公司其他部门的利益，无论是法律层面还是破坏其他产品都不可取。价值通常以金钱衡量，但公司有时也会重视其他要素。
若工程师在缺乏客户和/或高层严格指导的情况下自主决定开发方向，结果往往不尽如人意。此处情况正是如此——纯粹为技术而技术。我理解这里是HN社区且存在技术倾向，但工程师通常并非最优秀的战略家。
客户和管理层必须始终参与决策流程。这在原文引述和我的评论中都有体现。
我只是认为自上而下的微观管理极其痛苦，对客户不利，也浪费高管时间。这不是理想的工作状态。
作为工程师，你应当熟悉用户需求。我投身这个领域正是因为热爱通过自动化解决方案帮助用户解决问题。因此我当然需要了解用户行为，并能预见哪些改进能真正提升他们的生活品质。
文章核心在于他并非产品团队成员，仅负责为同事开发内部工具，自然无需承担那些管理负担
那些注定会出错的事？
没什么，除非小行星撞上大楼把整个团队灭了？
我感觉拉利特想做实事拿薪水，同时避开职场博弈。这种想法可以理解，但以我过去的经历，现实远不如想象中美好。
以我的经验，能让你安稳工作十年而不遭裁员或重组的科技公司极其罕见，更别提那些还提供有竞争力的薪资了。
若你正寻求新工作并希望提升职位和薪资，多年从事同类乏味工作反而会成为阻碍。
并非我刻意回避职场博弈(我认为自己至今并未回避)，而是职场博弈的规则会因环境而异。
虽然话题有些偏离，但若您有兴趣撰文探讨，我非常期待阅读您在技术导向型工程领域(而非聚光灯下的岗位)获得职业发展的相关经验——无论是书籍推荐、人物访谈、实践经历还是专业心得。
我虽身处航空航天领域，但正尝试开辟类似的职业道路，始终在探索如何成为更优秀的工程师。
> 若您有兴趣撰文探讨
未来数月我确实计划深入探讨这个话题 🙂 看到Sean的分享以及本文引发的共鸣，似乎确实存在对此感兴趣的群体 🙂
> 书籍、人物、经历、职业经验
书籍倒不是重点，但我非常幸运地拥有了优秀的导师。从加入谷歌起就跟随同一位经理，仅通过观察他的工作方式和人际交往，我就收获了 极其 宝贵的经验。此外还定期交流其他团队的几位资深总监/工程师。
若感兴趣，敬请关注博客更新 🙂
我一直坦诚地告诉我的经理，我不会在这个组织里玩“政治游戏”——其实我根本不必玩，作为工程师，有足够多的技术挑战可以让我拥有长久的事业，无需背负管理的枷锁。
还有另一种避开聚光灯的方式——当你数次成为焦点却毫无回报时。
精彩的帖子。这也提醒我们：并非所有人都适合同一条职业道路。
作为开发工具公司从业者，最令我感兴趣的是这凸显了供应商能提供什么(以及不能提供什么)。每次将开发工具集成到产品中，你都在信任对方已完成深层的维护流程设计与实践。
> 若我当年采纳“追求可替代性”的建议(即2023年为追逐新项目转投其他团队)，Bigtrace就不会存在。
在常规团队中，产品经理是否应承担此类宏观思考的责任？
> 在更常规的团队中，产品经理是否需要承担这种宏观思考的责任？
优秀的产品经理在产品团队中确实如此。但遗憾的是，产品经理同样会面临优先级变动和岗位调动，正如我描述工程师的情况。因此要实现这种模式非常困难，但我认识的顶尖产品经理总能设法做到！
这话听起来有点刻薄又愤世嫉俗，但我发现基础设施和开发者体验团队里产品经理的作用微乎其微——他们通常缺乏技术背景来构建相关的产品愿景。在这种团队里，任何能达到L7+级别的工程师都应该能自己想明白产品该是什么样子。
产品团队则不同，工程师并非最终用户——尽管我仍坚持认为产品工程团队的高级成员至少应具备基础的产品意识。
文笔精妙，洞见深刻。感谢分享！
回避聚光灯有害无益。
作为咨询从业者，我发现保持个人成就的可见度至关重要。
今年早些时候我为某客户做演示时，对方CEO意外到场。我的演示令他们惊叹不已。
运气需要自己创造。
你差点把我的电脑关机了，哈哈
当你身处特权地位——或许是全球顶尖的软件工程公司，凭借实力与高度运气取得今日成就时，写出这样的博客文章很容易。
有些人必须付出更多努力，甚至比你更优秀才能获得你一半的成就，这并不意味着他们错了，也不意味着书中的观点有误。
我认为书中绝大多数建议都是必要的。虽然别人未必能在谷歌工作，但正如我之前所说，他们可能需要通过不同方式努力才能成功——如果你不需要这样做，那恭喜你！
你的许多建议在多数公司会让你迅速被解雇，幸好这些方法对你有效。
本文并非宣称这是通用的成功模板，只是分享对我有效的路径。
我多次强调：确实存在更适合“快速行动并保持领导力”的场景，但这种模式仅适用于能长期维持基础设施团队的大型企业。
这绝非运气使然。如此推测甚至断言，既是无知更是无礼。
跻身这些岗位需要付出海量努力。没错，这确实是场艰苦的磨砺。
若你认为仅靠运气就能达成，恐怕是在低估自己。
运气成分显然很大。你没靠努力摆脱出生时的脑损伤，没靠努力选择出生在能获取资源的地理位置——这些资源让你走到今天，而世界上多数地方都无法获得。你也没靠努力逃避征兵，避免在18岁参战时丧命。
当然，如果受孕那天有只蝴蝶掠过父母眼前，让他们多看它一眼，当晚的亲密行为或许就会不同，我们便不会存在。我们每个人都是以十亿种方式赢得彩票的人。
在考虑职业发展行动时，将这种认知付诸实践有何意义？
嗯…好吧。
> 这并非运气使然。如此断言实属无知且失礼。
他们从未这么说过。他们只是指出其中包含高度的运气成分。比如在能接触电脑的国家成长，实现目标自然更容易些。
> 如果你觉得这只能靠运气实现，那我建议你别低估自己。
它绝对只能靠足够的运气实现：同样的“努力”，地球上并非人人都能达到同样的高度。人们竟不明白这点，实在令人惊讶。
这并不意味着没有付出努力。只是那种“我能走到今天，是因为世上无人比我更配得上，运气根本无关紧要”的说法…该怎么形容呢…自恋？
每家公司都有这类员工级职位。但竞争异常激烈。你必须持续证明自己足够优秀，让高管确信放手交给你也能解决问题。这里的“你”指的是你的团队，作为资深工程师，你手下很可能有许多初级工程师。
我弟弟曾在一家中型公司实习，六个月后，他参与开发了新产品(基本上就是为这个项目招聘的)和三款内部工具(包括一款数据追踪阅读工具，读完这段后感觉特别应景)，最终被聘为资深工程师。
我虽不具备他的主动性，也不擅长人际交往，但最终还是顺利入职了网络安全基础设施/工具团队。
>聚光灯
说真的，谁啊？
我在几家公司工作期间曾与这类人密切共事。这不过是那些“混够年限”后既无能力也无意干活的人设计的退休计划。如今身为有机会给潜力企业高层提建议的人，我总告诫新晋CTO们：要么别雇他们，要么解雇他们。
资深工程师及以上职位=45岁足球替补领着22岁前锋的薪水。
所以你建议仅凭头衔就解雇员工？这想法简直蠢透了。
我理解成你主张因年龄解雇员工。这并非愚蠢，而是恶意。
> 我理解成你主张因年龄解雇员工。这并非愚蠢，而是恶意。
“高级工程师”头衔可不是靠年龄获得的。
同样，解雇员工也不该基于年龄。解雇的理由是坐着不干活。那些“高级工程师”及以上职位的人往往就是这样坐着不干活。任何理智的公司解雇他们都是明智之举。
谷歌初创时期，绝不容忍工程师拿着华丽头衔却无所事事的现象。那时谷歌成就非凡，充满创新精神，因为公司每个成员都渴望有所作为。如今谷歌已沦为标准垃圾公司，高层尽是些坐在豪华座椅上空谈工作生活平衡的家伙，整天数着日子等着期权行权，好再去享受几个月的长假。
> 所以你建议仅凭头衔就解雇员工？听起来蠢透了。
你可以翻翻本评论区及其他讨论“高级工程师”和“资深工程师”的帖子。人们完美诠释了公司解雇他们为何明智——他们把这职位当作梦想中的“退休”工作。
没错，我建议解雇他们每一个。这群人毫无产出，却吞噬着巨额薪酬。
那人到一定年纪该怎么办？
继续工作，或者靠积蓄生活。
你明明说要解雇他们/根本不雇佣他们。毫无宽容余地。
没错。要达到资深工程师级别，你至少在行业里干了十年赚了大把钱。你存了些钱吧？对吧？