文章翻译来的，但是非常的贴切目前行业内的问题。你是否愿意做一些团队管理的胶水工作？ 这样做如果不能带给你晋升(但是对团队有益)，你是否还需要继续做？ 有没有什么建议？ 对此有困惑可以认真阅读。 你的职位是“软件工程师”，但似乎你花了大部分时间在开会。你很想有时间编码，但没有其他人来培训初级工程师，更新技术路线图，和用户交流，注意到被搁置的事情，就设计方案提出问题，并确保每个人都大致朝着同一个方向前进。如果你停止做这些事情，团队就不会那么成功。如果这描述了你，恭喜你：你是这个团队的胶水。如果不是，你有没有想过在你的团队中是谁在担任这个角色？
组织中的每个高级人员都应该意识到使团队成功所需的不那么光鲜、通常不太容易提升的工作。经过有意识的管理，胶水工作能够展示和建立强大的技术领导力技能。如果不经意间忽略了这些工作，它可能会限制职业发展。它可能使人们转向较不技术性的角色，甚至离开整个行业。
让我们讨论如何有意识地分配胶水工作，有益地构架它，并确保每个人都选择了他们真正想追求的职业道路。
你知道软件工程团队中每个人都整天只编写代码，然后项目后来取得成功的情况吗？不，这不是事实。项目不是那样运作的！
当然，编码是软件工程团队中的一个重要技能。但我们每天上班还需要许多其他技能。这些技能可能是项目成功与失败之间的关键因素。
比如，注意到团队中其他人遇到了问题，并帮助他们解决。或者审查设计方案，看到哪些地方被含糊其辞，或者哪些地方不一致。或者对新成员进行入职培训，让他们更快地提高工作效率。或者改进流程以让客户满意。 我把所有这些都称为胶水工作。
这是技术领导力，所以在高级工程师的领导层面试中我们确实会为此获得一些信息。
但有时候，一个团队中可能有一些不是高级工程师，但碰巧擅长这方面工作的人。有些人在还不是高级工程师之前就已经表现得像高级工程师一样。这种工作使团队变得更好——有很多这方面的工作需要完成。但人们并不总是因为做这些工作而得到奖励。 事实上，过早进行胶水工作可能会对职业发展构成限制，甚至可能导致人们离开这个行业。
这很具有讽刺意味。我们失去了一些优秀的工程师，因为他们碰巧还擅长我们需要的其他技能。 今天我想谈谈胶水工作。 这是我们的议程：
-
我将讲述一个关于一个人因为胶水工作而受到职业伤害的故事。虽然不是完全真实的故事，但是它是许多真实故事的结合体。我已经进行了几次这样的演讲，收到了许多令人惊奇的来信，告诉我这也是他们的故事。
-
然后我们将讨论公平性，既包括故事结局的公平性，也包括工作分配的公平性。
-
接下来我们将讨论是否以及何时离开IC工程师的轨道，成为人员经理、产品经理等。我想很多阅读这篇文章的人在某个时候都曾为这个决定而苦恼。关于如何做出这个决定有很多不同的意见，我将给出其中之一 :-)
-
然后，如果你一直在做很多胶水工作，如何为自己的工作设定框架，以及如何使你的影响可见。或者如何帮助你的同事或下属做同样的事情。
-
最后，我想谈谈学习和成长，这是我认为我们这个行业没有充分讨论的一个方面。
好的，讲故事时间。想象一位软件工程师......
她，第一天加入一个新团队。她已经毕业几年，有过前几份技术工作经验。她对自己的技能并不是非常自信，但喜欢这项工作。
新的代码库非常复杂，她的第一次更改花了很长时间。这是正常的，但每个人都忙于自己的事情，没有人理会她。她觉得自己工作得太慢，需要太多帮助。几周后，她担心自己过不了试用期。
然后她迎来了第一个胜利。一个客户提出请求：他们想要API应该能够提供的数据，但团队还没有将这个功能列入优先级。我们的朋友花了几天时间手动获取客户需要的数据。客户感到非常高兴。
她记录了如何获取数据以及团队在Slack上经常被问到的其他问题的答案。团队不再受到那么多打扰。客户高兴，其他软件工程师也高兴。
好的，回到那个困难的代码。
过了一段时间，她与附近团队的人交谈。他们似乎对正在解决的问题有不同的看法，而且朝着不同的方向发展。她与团队的系统设计师安排了一次会议，并提出了很多问题。事情改变了方向。现在他们一起工作，构建出更好的东西。她在会议上做了笔记并发送给大家，以确保每个人都对达成的共识有一个共同的理解。
再后来，又有新人加入团队。她记得自己刚入职的困难，整理了一堆入职文件。因此，她建立了一个导师计划，所以以后所有新人都会得到一个导师。
公司一直发生故障，这些故障通常归咎于代码库中缺乏测试。她召集了一群高级人员，并不断推动，直到他们同意整个组织的编码标准。现在所有的代码都会更有测试，更可读，更可靠。回滚的次数更少。由于代码风格一致，代码审查变得更快。
他的经理负责多个团队，需要横向拉通，但陷入了长达三周的电子邮件讨论中。她与这些人面对面交流，弄清楚混淆的原因，解决了问题。出色解除了阻塞问题。他说谢谢，写了成千上万行的代码。由于她现在对项目有了很多了解，我们的工程师为他写了文档和上线计划。项目按时上线。
大家都说干得好，出色的程序员。
就这样过去了两年。这名工程师一直发誓她将很快写更多的代码...
...但每天都会出现更重要的事情。团队已经开始把她当作非官方的领导。她对正在发生的一切都有一个广泛的了解，可以发现设计之间的负空间，并指出需要发生的额外事情。她与每个人都有一对一的会议。她指导所有新人。
当她有空闲时间时，通常是在两次会议之间的一个小时或两个小时。在短短的时间内将代码放入她的大脑，然后参加会议的想法真的很痛苦。
她并不担心，因为每个人都告诉她她的工作有多棒。她总是得到很好的绩效评估。事实上，她感觉自己已经提升了一个层级。
让我们看看她公司的晋升流程是否同意。我们应该晋升谁？
嗯，显然是那个写了那么多代码的人！干得好，出色的程序员！
以及为该项目设计并使其与另一个团队构建的东西完美集成的人！ 干得好，系统设计师！ 然后是... ...就是这样。等等，什么？ 为什么不是我？ 你的项目还没有完成。你没有写太多的代码。你的影响力还不够。 但我减少了入职时间。 我注意到我们正在建造错误的东西，让我们改变了方向。 我们的客户说我是唯一帮助他们的人。 我引入了编码标准和测试指南，现在我们的代码审查更快，回滚更少。 我审查所有我们的设计文件，我留下的评论和我提出的问题让我们建造了更好的东西。 他们说：“是的，这是好工作。但你真的没有做出技术贡献。” “那不是技术的吗？我的意思是，这不是代码，但并不是所有技术工作都是代码......” 他们说：“看，你在沟通方面很棒。你的软技能出色。我们只是觉得你不是一名工程师。考虑转行成为项目经理怎么样？” 那么这是公平的吗？在每个时刻，这位工程师都在做着最高影响力的工作。如果没有她，项目不会上线。她是让整个项目紧密结合在一起的关键因素。 在过去的两年里，她真正擅长了技术领导：理解问题域，理解人员，引入标准，改进设计。但她确实在编码方面没有真正进步。 对此我们该怎么办呢？她是一名高级工程师吗？ 如果你在这里感到矛盾，没关系！我已经问过这个问题很多次了，得到了各种各样的回答。有几个人说答案是如此明显，以至于不需要提出这个问题（尽管他们对答案并不一致），但大多数人对此感到矛盾。 我确信的一件事是，她的经理在这里承担一些责任。存在沟通失误。 这不应该是一个意外。这位工程师得到了极好的绩效评估。她相信自己正在走向高级工程师的道路。而且你知道，她做了那种我期望高级工程师甚至是高级工程师要承担的工作并解决的问题。她绝对掌握了领导力的一部分。
但这家公司并不认为这是足够晋升的工作，至少在这个层面上是这样。尽管他们没有明确这样说，但他们想要代码或其他可量化的技术工作。而她的经理从未告诉过她她做了太多非晋升的工作。可能经理只是很高兴胶水工作得到了完成。因为总得有人做这个。
胶水工作是项目成功与失败之间的差异。这就是为什么技术项目经理和项目经理产生如此大的影响：他们扮演着终极的胶水角色。他们看到缺口并填补它们。
在没有项目经理的团队中会发生什么？在某些团队中，经理会承担这一负担。在其他团队中，这项工作分散给愿意做的人，或者是那些预计会自愿做这项工作的人。
我阅读了哈佛商业评论上关于志愿工作的一篇文章（如果你更喜欢的话，还有一份附带的 35 页出版物）。文章显示，当有非晋升相关的工作要做时，女性比男性更愿意自愿承担这项工作多达 48%。
但他们还发现，男性之所以自愿较少，是因为如果他们等待，他们知道会有女性自愿。在全男性团队中，他们毫不费力就能找到志愿者。如果那里没有女性，男性照样自愿。
更有趣的是，当经理被要求选择某人来做感谢工作时，他们问女性的机会比问男性多出 44%。 我想澄清的是，我并不是说你的工作需要100%是可晋升的工作。培养辅助技能、拓宽视野是有益的，每个人都应该公平地分担一些琐碎的工作。但你的工作中应该有很大一部分是你被评估的内容。如果有人几乎没有完成他们的核心工作，那么他们正在损害自己的职业生涯。如果你是他们的经理并允许他们这样做，你就是在让他们伤害自己的职业生涯。
非晋升相关性工作是那种“一个人的垃圾是另一个人的宝藏”的事情。比如，如果一名工程师组织了一次团队外出活动，那就是非提升性工作，但管理人员可能可以声称团队建设是他们工作的一部分。如果是一名活动协调员这么做，这可能就是他们的核心工作。
当存在真正对任何人都是非晋升性的工作时，这项工作需要被共享。这项工作需要以团队追踪其他工作的方式进行跟踪，并需要有意识地进行分享。如果这项工作只是由随便哪个人接手完成，那么它就不会被公平地分配。
我邀请你花一些时间思考一下在你的团队中是谁在做非晋升性工作。
好的，回到我们的故事。现在有人建议她转向一个角色，那里同样的工作将是可帮助晋升的。我经常看到这种情况：一种“你正在做不可晋升的工作，所以改变你的角色”的信息。我还没有看到太多关于“所以改变你的工作”或者“所以改变你讲述工作的方式”的强调。
让我们谈谈改变角色。我已经阅读了很多关于是否要从事某种角色的文章。其中大部分是正在从事某项工作的人谈论你是否适合做那项工作。就好像能够做某事就意味着你必须做那件事。
他们说：你能否处理给予反馈，你喜欢指导，你喜欢与人打交道吗？那么你应该成为一个经理。
你能否将自己放在客户的角度来考虑？那么，是的，恭喜你，你是一个产品经理。问题解决了。 但这就像游乐场上的那些标志：“你必须有这么高才能玩过山车”。 “好吧，我够高了，但那看起来很可怕。”
“你必须有这么高的社交能力才能成为经理。” 我有，但那不是我想要的好时光！
我有自己的衡量标准。如果你编码，你会变得更擅长编码。如果你管理人员，你会变得更擅长管理人员。
所以……
... 你想变得更擅长什么？ 你想要哪些技能？这不是关于你已经拥有哪些技能！你希望拥有哪些技能？我们绝大部分的学习发生在工作中。
但我看到有些人不考虑他们想要的角色，因为他们觉得自己还没有那个工作所需的所有技能。我听过很多计算机科学专业的学生告诉我，他们不申请编程工作，因为他们觉得自己不是优秀的程序员。
当然他们不是！他们还在上大学。我们绝大部分的学习发生在工作中。 他们最终选择了一个他们不想要的角色，因为他们害怕做他们真正想要的角色，或者因为其他人告诉他们他们在另一个角色上会很出色。
我建议人们要有意识地选择。选择一个让你感到成功、快乐和自豪的角色，能够教授你想要学到的技能。做一份让你激动的工作。通过实践，你将学会做得很好。我觉得我们不够经常承认的是，大多数情况下，我们在第一天不会做好一份工作。我们绝大部分的学习发生在工作中。
然而，还有另一个考虑因素，尤其是当人们在大学或初级阶段做出这个决定时。从一个更技术性的角色中退出会关上一些门。这是不公平的，但我们行业的偏见设置得很明显，以至于在你转向非工程角色之前，你真的需要有一个扎实的工程简历。 因为一旦你放弃了那个“工程师”的头衔，一旦LinkedIn上最近的工作经历中没有“工程师”这个词，行业中的一半人会认为你现有的技术技能永远消失，而且你不可能再学到更多。我不知道这个脑科学是怎么运作的，但这是一种非常普遍的隐性偏见。
特别是如果你的职称是任何“项目经理”变种。很多人会立刻认为你在技术方面不擅长。
Google云产品运营部门传奇总监Kripa Krishnan曾经说过，尽管她因为是女性和有口音而在行业中经历了一些偏见，但与她作为TPM所经历的偏见相比，那简直微不足道。
项目经理和TPM经常被工程师低估。 "Lost technical skills."
我看到很多人接受了这样的角色，并发现自己被推向非技术的经理或项目经理：这是离开这个行业的一步。我见过一些人回头看工程师的工作，发现即使是最近的经验，他们也无法以他们曾经的开发者水平被雇佣。仿佛他们拥有的技能已经蒸发了。
他们必须以比离开时更低的级别进入，因为人们不相信他们有能力胜任这份工作。他们无可避免地会听到这个行业里最令人恼火的三个词：“失去技术技能”。"NOT TECHNICAL ENOUGH". 这是什么鬼。这里的“技术”是什么？你怎么用这个说法采取具体的行动？这太依赖领域了！
如果你曾经有过告诉某人他们不够技术的冲动，首先，最好别这么说。但请非常具体地说明你希望他们了解的内容。比如：
"你需要理解并参与设计会议中的技术讨论，请熟悉这组技术的权衡。我推荐一本书给你。
或者：“我们的高级工程师都是系统设计师。请上一些分布式系统的课程，对CAP理论有一些看法。
否则，你基本上只是在说……
"你真的不像一个工程师。能不能更像个工程师？"这是守门人行为。这不是切实可行的反馈。这让我们回到了我们的朋友身上。
两年前，她作为中级工程师加入。从那以后，她一直在填补空白，以使团队和组织取得成功。结果，她刚刚被告知她没有技术上的成就。
她想要晋升。 让我们谈一谈这个。我非常强调职业发展，这对每个人来说并不是首要任务。这没问题。这里有一个我明确的偏见：我希望这位工程师女士感到充实，同时也能获得长期的财务安全。她希望有一天退休并买一艘小船。我想帮忙实现这个愿望。
我不知道她的正确职业选择是什么。只有她能做出决定。她应该有意识地选择，基于：
- 她想要在哪方面取得进步？
- 什么工作会让她感到开心和自豪？
- 她愿意将哪些门变得难以重新打开？
不幸的是，还有一个：
- 她在哪里会感到安全？如果她选择一个她不太激动的角色，但在那里她感到更受支持，更不孤独，我不能因此指责她。但我希望她能做自己热爱的事情。
不管她最终作出什么决定，我都将尊重她的选择 :-)
由于我没有时间在幻灯片中进行“选择你的冒险”，因此在接下来的谈话中，我们将假设她决定继续担任工程师，因为我认为我们没有足够讨论资深 IC 路径，而我个人是其粉丝。
所以，她想成为一名资深工程师，实际上，她已经在做大部分这份工作。但她得到了很多“不够技术”。
如果你是胶水，你该怎么办？如果你在管理一个胶水的人，你该怎么办？如何确保不浪费这种宝贵的技能组合？这里有一个四步计划。
首先，这位工程师和她的经理需要进行一次长期未谈及的职业对话。她需要直接提问，比如“我会在下一轮晋升吗？”“我需要做哪些工作才能获得晋升？”“这是资深工程师的工作吗？”
她的经理也需要坦诚而直接，基于对职业阶梯的理解。他们需要达成共识，制定计划，并定期进行检查以确保他们仍然在正确的轨道上。
第二，一个职务头衔。如果她和她的经理希望她继续做大量的胶水工作，是否有一个能为她赢得技术信誉的头衔？她能否成为技术负责人或其他头衔？人们期望领导要做大量的胶水工作。
好的，可能有些人正在阅读这篇文章并认为头衔不重要。也许对你来说确实不重要，网络朋友！但这并不意味着其他人不重要。
看，如果你是个白人或亚裔小伙，人们默认情况下会认为你擅长编码。你昨天可能刚刚拿到法学学位，人们就会认为你会编码。
对于我们其他人来说，我们不会得到这种免费的假设。一个职称能够为我们省下一些不必要花在证明自己资格上的时间和精力。它为我们在一周内节省了一些时间。
并且它给了我们一些自由，可以在人们认为我们“不够技术”之前继续做胶水工作。
如果你告诉你组织中的少数族裔成员头衔不重要，你在误导他们。头衔非常重要。
第三，她需要一些显示她影响力并讲述故事的工作成果。由于她的工作和技术判断力，某个事情发生了。
她的经理也应该讲述同样的故事。如果你看到这种情况，其中一个胶水人员是某事成功的唯一原因，请公开给予他们赞誉！不是为了帮助，而是为了领导。
她应该创建和保存证明这个叙述的工作成果：设计提案、会议记录、团队邮件、她促使事情发生的关键时刻。
现在，这可能仍然不奏效。也许六个月后，晋升的人再次说不。在这种情况下，我有一个有点愤世嫉俗的解决方案。如果你因为做胶水工作而得不到晋升…
停止做胶水工作。我建议她 - 暂时 - 完全按照职业梯队上的规定去做，即使这意味着放弃更重要的事情。她应该做一些容易量化的技术工作。写很多代码。撰写一些任何人都可以写的设计。学会优化数据库的性能。做一些毫无争议的“技术”工作。
即使她不是团队中最擅长这方面的人，即使她生疏并且比其他人慢很多，她也应该这样做。
但问题是，这意味着她必须停止做其他事情。
编码无法适应整个胶水工作的日历。因
此，我建议她，在晋升完成之前，宣布许多事情都与她无关。
停止面试，停止组织团队活动，停止入职，停止处理用户的请求，停止任何听起来像团队建设的事情。停止帮助其他人完成工作。归档邮件。退出 Slack 频道。不要制定团队路线图。
关键是：不要去解决即将掉落的事情。对于我们许多人来说，这非常困难，但请记住，团队中的其他成员已经在做这件事。
不要再担任非官方领导角色。（如果你处于同样的情况，并且是官方领导，考虑是否也停止这样做！）
然后…唉，我讨厌说这句话，请原谅我，但如果她为公司做了很多多元化工作，我建议她暂时停止做多元化工作。
获得晋升也是多元化工作。成为公众成功的人是她能做的最有力的多元化工作。她可以成为某人需要的代表。她可以更好地进行导师和赞助。但她需要在日历中有空闲时间。
只有将许多事情宣告为与她无关，她才能从这个状态…
…变成这样。 （最好是比这个好，但这是我能制作的最好的日历截图 :-））那些大的空白空间很适合用于项目工作、编码、撰写设计等。而且这项工作将产生一个副作用，即执行循环，执行它的人会变得更擅长编码和撰写设计。
这个术语的技术术语是学习 :-D 我们绝大多数的学习都发生在工作中。如果你希望拥有的技能是你整天在工作中做的工作的一部分，那么你会免费获得一定数量的学习。每次你查找 Stack Overflow 时，你都在学到一些东西。但对于你不断做的任何事情，你必须去选择学习它。
即使对于那些因胶水工作而得到认可且希望继续做的人，我真的建议你们继续提升你们的其他技能。
如果你只做胶水工作，你只会在胶水方面变得更好。你让团队更有效，但伤害了你未来的自己。无论你最终做什么，你都不太可能后悔在核心技术技能上感到更加自信。
学习是我们的行业不怎么谈论的事情。人们脑中的所有技术知识都以某种方式学到的。但我们并不真正承认这需要时间。
如果你是一名资深人员，请向你组织中的初级人员展示你正在学习以及你是如何做到的。公开说明你正在学习的内容。
有些人有幸拥有免费的学习时间。其他人则有义务，这意味着他们根本没有空闲时间。
因此，请明确表明，在工作时间内学习是可以的 - 甚至是正常的。
将你的中级人员培养成为高级人员是一个不错的投资。永远不要浪费一个让人们学到东西的机会。
更重要的是，注意一下你正在浪费的学习机会。如果你总是为别人做事情，你就剥夺了他们的学习机会。
如果有一些事情你总是做，而你知道怎么做，找到一个从中受益的人，然后请他们 - 友好地！
