程序员的晋升困境

点击蓝字，立即关注

你是一位工作多年的程序员，在公司的职位是”软件工程师”，用国内常说的职级体系来看，你是一个 P6，一线干活写代码的大头兵。但在日常工作内容中，却并没有太多时间去写代码，似乎大部分时间都在开会，不停地开会。你希望能够有时间停下来写代码，但似乎有更多的工作需要你来做，比如：

• 给刚毕业的校招生讲解业务知识，帮助他们更好地解决工作中的问题；

• 与其他合作团队沟通、对齐，帮助团队成员梳理工作内容，解决问题；

• 认真阅读团队成员的技术方案文档，给他们提各种名样意见和建议，防止项目上线后出现问题；

• 像一个客服一样，积极地为客户们解答疑问，排查问题出现原因；

• 帮其他人「擦屁股」想方案，确保项目不会出现异常；

• ……
  

这些工作，我称之为“黏合剂”工作，原则上它们都不是一个软件工程师的本职工作。它们让你忙得不可交，没有时间写代码，也没有时间学习，但一周工作下来，到写周总结时，却又仿佛你什么都没有干。认真思考一下，你在团队中是不是或多或少都在做这些事情呢？如果你没有做，那你们团队是谁在做这些事情呢？

当然，如果没有人干这些事情，而专注于写他们自己的代码，团队的项目可能会乱成一团，一些项目也可能会出现一次次的延期。团队中的每一位资深人员都应该知道这些琐碎的工作，对于团队的发展至关重要，他们也知道，这些工作大多数情况下对自己「升职加薪」没有太大的帮助。如果你能有条不紊地管理着这些项事务，确保每一项工作都得以高效完成，通过这些“黏合剂”工作可以培养强大的技术领导能力。但是，如果处理不好，它可能会对你的职业生涯造成影响，甚至导致最终离开这个行业。

“黏合剂”工作到底要不要干，要怎么干？先来看一个小故事：

一、张三的成长之路

今天是张三入职「驴厂」的第一天，怀着激动而忐忑的心情。他已经毕业好几年，在软件开发的工作上积累了丰富的项目经验，但是这毕竟是国内数一数二的大厂，他对自己的技术能力有一些不太自信，但是非常喜欢这份工作，也相信以自己的能力可以干好。

部门的项目经过多年的「积累」，虽然有大量的系统设计文档，但其中夹杂着不少黑话，使得文档难以理解，阅读起来往往感到困惑。代码也同样如此，堆积多年的兼容逻辑导致代码变更显得异常复杂，他的第一个需求做了很长的时间才成功上线。这其实是一个很正常的现象，部门内的同事虽然都很友好，但大家都忙于自己的事情，无暇顾及，也没有给他任何帮助、对他表示安慰。以致张三觉得自己能力不太好，工作太慢、需要太多帮助，他开始害怕试用期无法正常通过。

不久后，他完成了一项工作，得到了客户的极度好评：客户需要捞取用户的使用数据报表，按理来说，系统中应该提供对应的功能，方便客户自行查询，但团队工作量中并没有把这项工作列到未来待实现的功能中。而张三花了几天时间，将客户需要的数据整理清楚并提供给客户，这让客户非常满意。除此之外，他将此次获取数据的方法和步骤记录在了团队的文档中，并分享给团队同事，这让团队成员在处理此类问题时，效率得到了极大的提升，方便了同事们的工作，而客户也很满意。

张三按部就班地进行着每天的工作，直到有一天，部门项目出现了一个棘手的问题，但当时并没有找到太好的解决方案。经过内部讨论，团队得出了一个初步的方案。与此同时，张三向隔壁团队的同事咨询了相关内容，发现他们有不同的解决思路。于是，张三组织了一次会议，邀请了自己团队的系统设计师和隔壁团队的同事。他在会议中提出了许多关键问题，并经过充分讨论后，两个团队决定合作，共同打造一个更好的产品。会议结束后，张三整理了会议纪要并发送给所有参与者，以确保每个人都对达成的共识有一致的理解。经过开发，最终很好的解决了客户的问题，提升了公司的收益。

时间慢慢流逝，张三逐渐成为团队中的资深成员。随着新成员的不断加入，他想起自己刚入职时的艰难经历，于是组织同事编写了一些新人入职文档，并建立了一个「新人落地计划」，为新成员配备导师，帮助他们更快融入团队。

随着对业务的深入了解，张三发现代码库中严重缺乏单元测试。为此，他召集了一些经验丰富的老员工，持续推动改进，制定了编码规范和代码合入流程。现在，所有代码都有了更完善的测试、更高的可读性和更强的可靠性。

随着解决的问题越来越多，张三在团队中的地位逐渐提升，部门负责人也开始通过他来了解团队的情况。有一天，团队里那个「优秀的程序员」负责的项目出现了延期，可能无法按时交付给客户，老板让张三去调查情况。张三花了很多时间了解事情的来龙去脉，发现「优秀的程序员」的项目需要从另一个团队的服务中获取信息，但经过三周的讨论仍未达成共识。于是，张三带着「优秀的程序员」与另一个团队的人进行面对面的交流，很快解决了这个问题。最终，「优秀的程序员」完成了所有功能，项目按时交付，张三在项目正常推进中做出了巨大的贡献，但所有功劳都归到了那个「优秀的程序员」身上。

两年时间就这样过去了。张三不断对自己发誓，一定要抽时间写更多的代码，但每天总有更重要的事情出现，他的日程被排得满满当当：

团队成员已经开始将他视为非正式的负责人。他对团队中的一切了如指掌，能够发现系统设计中的问题，并提出有效的解决方案。他经常需要与团队成员进行一对一的沟通，并指导所有新成员。唯一的空闲时间是在会议之间的一两个小时，然而要在这短暂的时间内专注于写代码，几乎是不可能的。不过，他并不担心自己的发展，因为每个人都告诉他，他的工作非常出色，而且他始终能够获得最好的绩效。经过两年多的成长，他觉得自己已经达到了一个新的高度。

然而，在公司的晋升流程中，提拔的往往是那些代码写得好的人，比如前面提到的“系统设计师”和“优秀的程序员”，而张三却没有被提拔。

尽管张三帮助了客户，制定了编码规范，协助同事评审系统设计文档，虽然我们都知道并不是所有的技术工作都需要亲自写代码，但老板依然会告诉你：

你的项目还没上线。

你没写多少代码。

你还没有足够的影响力。

你的沟通能力很强。

你的软技能非常出色，只是我们不认为你是一名合格的工程师。

要不要考虑做项目经理呢？

二、晋升困境：能力与制度的碰撞

故事中的晋升机制对张三真的公平吗？张三在每个项目的关键节点上，都是承担着最具影响力的工作。没有他，许多项目可能根本无法按时交付。他是将整个团队和所有项目紧密联系在一起的“黏合剂”。在过去的两年里，他在技术领导力方面快速成长，表现得非常出色：不仅深入理解项目中的问题，还非常了解团队成员的需求，引入标准、优化设计，极大地提升了效率。虽然在编码能力上的提升相对有限。

我们该如何看待这种情况呢？他可以晋升为高级工程师吗？

是不是觉得按能力应该晋升，但按制度却不该晋升，这种矛盾感很正常！这个问题得到的答案五花八门。还有人认为答案显而易见，根本不需要提出这个问题（尽管他们的答案并不一致）。

但有一件事确信无疑：他的老板在这件事上负有一定的责任，他们对工作内容没有进行良好的沟通。张三每年都获得了非常高的绩效评估。他坚信自己正迈向晋升为高级工程师的道路。而且，他确实承担并解决了对高级甚至资深工程师所期望的那些工作和问题。他的领导能力毫无疑问是非常出色的。然而，这家公司并不认为这些工作足以让他晋升，至少在好的这个级别是不行的。虽然他们没有明确说出来，但他们真正看重的是代码或其他可量化的技术成果。而老板却从未告知他所做的这些工作并不足以支撑晋升。老板可能只是欣慰有人愿意承担这些“黏合剂”工作，因为这些工作确实需要有人来做。

“黏合剂”工作往往是项目成功与否的关键。通常这些工作由项目经理来完成，但在没有项目经理的团队中会发生什么呢？在一些团队里，老板会主动承担这部分工作。而在更多的团队中，这些任务往往由愿意做的人来承担，或者由那些被默认为应该自愿承担这类工作的人来负责。

三、聚焦核心，避免职业迷失

上述内容并不是说你的所有工作都必须直接有助于晋升。对于个人成长而言，培养软技能和拓展视野确实是有益的。在工作中，每个人都应该公平地分担一些“脏活累活”。然而，你的大部分工作应该聚焦在核心 KPI 上。如果有人长期偏离核心工作，这实际上会对他们的职业发展产生负面影响。而如果你作为他们的老板却放任这种情况发生，那你实际上是在让他们无意中伤害自己的职业生涯。

在日常工作中，工作内容往往如“汝之蜜糖，彼之砒霜”。对你的晋升不利的工作，可能对其他人的晋升却非常有利。比如，一个工程师组织了一次团建活动，不论办得多出色，都不太可能被视为晋升的依据。但如果这个人是 HRBP 呢？那么这项工作可能就是他们的核心职责。

对于那些对任何人来说确实不利于晋升的工作，它们应当被公平分配。这类工作需要像团队的其他工作一样被跟踪，并且需要有计划地进行分配。如果这些工作只是由随便谁来接手，那就无法保证公平分配。花点时间想一想，你的团队中哪些人承担了这些不利于晋升的工作?

好了，现在让我们把视线再次回到张三身上。有人建议他转岗到一个能够将这些工作转化为晋升助力的职位。我们见过很多类似的情况：传递的信息往往是“你在做不利于晋升的工作，所以换个职位吧”。很少看到有人强调“那么就调整一下你的工作内容”或者“改变一下你呈现工作成果的方式”。

我们来谈谈调岗的问题。我读过很多关于是否应该选择某个岗位的文章。大多数文章都是由那些已经在做这份工作的人撰写的，讨论你是否适合这份工作，似乎只要你能够胜任某件事，就意味着你必须去做这件事一样。他们会说：

• 你擅长处理反馈吗？你喜欢指导别人吗？你喜欢与人打交道吗？那你就应该做项目经理。

• 你能站在客户的角度思考问题吗？那么，你就应该做产品经理。

但这种刻板的思维方式就像游乐场的那些标志：“你必须达到这个身高才能乘坐过山车。”可是，我的身高够了，就意味着我必须去坐过山车吗？我具备很好的社交能力，我就一定要成为项目经理吗？但那可并不是我想做的事哇！

在我看来，如果你编写代码，就会逐渐变得更擅长编程；如果你管理人，就会变得更擅长管理。所以，关键是你想在哪些方面提升自己？你想获得哪些技能？这不在于你已经具备了什么技能，而在于你希望自己将来拥有的技能。毕竟，我们大多数能力都是在工作中学来的。

我见过很多人从未认真考虑过他们真正想要的工作，因为他们觉得自己还不具备那份工作的所有技能。许多计算机科学专业的大学生告诉我，他们没有申请过任何编程相关的工作，因为他们觉得自己的编程能力还不够强。他们最终选择了一个自己并不想要的工作岗位，因为他们害怕去尝试自己真正想要的职位，或者因为别人告诉他们，他们在另一个岗位上会表现得更好。

我建议大家要有意识地做出选择。选择一个能让你感到成功、快乐、为之自豪，并且能教给你所需技能的工作岗位。去做一份让你感到兴奋的工作。你会在这份工作中不断学习，并逐渐成为高手。大多数情况下，我们在第一天并不能把工作做到完美，大部分能力都是在工作中学会的。不过，当你尝试转向非工程类的工作时，你需要确保自己拥有扎实的技术背景，因为一旦你的工作经历中出现“项目经理”这样的词汇，很多人会带有偏见，立即假设你不擅长技术。我见过很多人接受了这样的 Offer，结果发现自己被安排去做非技术性的管理工作或项目经理岗位，逐渐远离了软件开发这个行业。而当他们想重新回到原来的开发者岗位时，却发现自己无法再被雇用到之前的级别，即使离开开发工作并没有多久。就好像他们的技能已经消失了一样。他们不得不以比离开时更低的级别回归，因为人们不再相信他们有能力胜任原来的工作。

在此我建议大家，不要告诉别人他们“不够技术”，面是具体说明你希望他们掌握哪些知识。比如：

• 你需要在设计会议中理解并参与技术讨论；

• 我们的高级工程师都是系统设计师，你需要学习分布式系统的课程。

否则，你基本上只是在说：“你看起来不像个工程师。能不能让自己更像工程师一点？”

四、贡献与成长，如何抉择

两年前，张三作为一名中级工程师加入公司。从那时起，他一直在帮团队填补空白，帮助团队和组织取得成功。然而，在晋升场上，他却被告知没有技术成就。

我不确定他的正确职业选择是什么，但他希望得到晋升。假设他决定继续走工程师的道路，成为一名高级工程师，事实上，他的工作内容大部分已经是高级工程师的职责。然而，他却频繁地听到“技术不够”的评价。如果你是“黏合剂”，你该怎么做？如果你在管理一个“黏合剂”，你又该怎么做？作为一个过来人，我有四个建议：

1. 沟通

张三应该尽早与他的老板进行一次早已该进行的职业对话。他应该问一些直截了当的问题，比如：

• 我会在下一轮晋升吗？

• 我需要做哪些工作才能晋升？

• 这些工作是否符合高级工程师的标准？

他的老板也需要基于对职业发展路径的理解，诚实而直接地回答问题。他们需要就目标达成一致，制定一个明确的计划，并定期检查进展，确保他们仍然在正确的轨道上。

2. 头衔

想办法获得一个合适的职位头衔。如果他和老板都希望他继续承担大量的“黏合剂”工作，是否可以考虑给他一个能够提升技术信誉的头衔？比如让他担任技术负责人之类的职位。通常，人们期望负责人会做大量的“黏合剂”工作，这样的头衔也能更好地反映他的贡献。可能有些人在读到这里时会想，头衔无所谓。也许你不需要它们，但是朋友们，这并不意味着每个人不需要。这个世界存在着各种各样的刻板印象，如果你是一个白人或亚洲男性，别人默认会认为你擅长编程。即使你昨天刚毕业，拿的是法律学位，但人们仍然认为你会编程。一个合适的职位头衔可以节省我们大量的时间和精力，不必花时间证明自己资历。它还能让我们有更多的自由去做“黏合剂”工作，而不必担心别人会认为我们“技术不够”。请记住头衔非常重要。

3. 包装

张三在工作中， 通过他的努力和技术判断，让项目得以实现。但他依然需要将成果进行一定包装、然后表达出来，让团队所有人都知道他的影响力。如果你作为一个管理者，看到了类似的情况，你也应该公开表达你的赞赏，表扬同事的领导能力。

与此同时，还需要将自己在工作中的材料整理出来，如方案设计文档、会议纪要以及那些解决问题的关键事项，将这些材料作为晋升陈述材料。不过，即使有了这些材料，也可能仍然无法顺利晋升。

4. 停止做“黏合剂”工作

为了更好地晋升，我会建议大家放下那些对公司、部门更重要的事情，严格按照职位阶梯的要求去工作，做更多容易量化的工作，一些大家都认可的“技术性”工作：

• 写一堆代码；

• 写一些任何人都能写的设计文档；

• 去优化系统的性能，优化数据库。

即使这些工作可能有团队中更适合的人来做，或者因为技能生疏导致你比别人做得慢，也依然需要去做。

编码工作非常耗时且需要高度专注，通常需要大块的时间才能真正投入其中。因此，在晋升通过之前，不要参与面试、不要参与组织团建，停止所有与团队建设相关的事情。最重要的是：不要去挽救那些即将被搁置的事情。

只有当你的日程变成这样的状态时，才能拥有大段的空白时间，专注于编写代码、撰写设计文档等工作。当你逐项完成这些任务时，它会形成一个良性循环，不断提升你的编码能力和撰写设计文档的能力。

这个过程就是学习。我们大多数的学习都是在工作中发生的。每当工作中遇到问题，你在 Stack Overflow 上搜索查找到答案时，你都会学到一些东西，这个过程是你反复进行的。但对于那些不常反复做的事情，就必须积极主动地去学习才能真正掌握。

五、持续学习，持续进步

对于那些喜欢做“黏合剂”工作的人，我也建议你们继续提升自己的技术能力。如果你一直只做“黏合剂”工作，你最终只会在“黏合剂”方面变得更擅长，而技术能力可能会停滞不前，这会影响你未来的职业发展。对核心技术技能的学习，几乎是不可能让人后悔的事情。

在我们所在的行业里，很少有人真正讨论学习的重要性。我们大脑中的技术知识，都是通过某种方式学到的，但我们往往会忽略学习过程中我们投入了大量的时间。

如果你是一位资深开发人员，我建议你向团队的初级员工分享你的学习内容和学习方法。我们中的一些人有幸能够拥有学习的空闲时间，而另一些人则因为各种工作事项，几乎没有任何时间学习。在这里，我想强调的是，你需要意识到在工作时间学习是可以的——而且是正常的；对于管理者来说，将中级员工培养成高级员工也是一项非常有价值的投资。永远不要浪费任何让人们学习的机会。

在工作中，如果你总是替某人做某件事，表面上看似是在保护他们，实际上你是在剥夺他们的学习机会。如果有些工作你已经非常熟悉如何做，那么你应该尝试将这些任务分配给那些能够从中受益的人。让他们在日程表上划出时间来学习，并在他们学习的过程中给予支持。这样不仅能帮助他们成长，还能为团队培养更多的能力。

我那位出色的同事 Polina 有一些很好的建议，关于她在面对别人试图把她推向 “项目经理” 工作时的应对方式：

同事/老板：“你应该做这件事，因为你在沟通方面非常出色。”

她会回答：“是的，只要我投入时间，我就能擅长，与具体事项无关。你应该看看我在系统设计方面的表现。”

所以，当她专注于设计系统时，沟通的事情便需要由其他同事去处理。她通过这样做，创造了一个学习机会，让其他同事也能提升他们的沟通能力。如果你是一名管理者，我建议你帮助团队中那些不擅长“黏合剂”的人也投入到相应的工作中。

还记得故事中的「优秀程序员」和「系统设计师」吗？他们之所以能够顺利完成工作，是因为张三帮助「优秀程序员」进行沟通，并为「系统设计师」梳理了他所构建的系统如何与公司正在构建的其他系统集成。我不认为这两位算是真正的高级工程师。而且，如果有人继续为他们做这些「黏合剂」工作，他们永远也学不会如何成为真正的高级工程师。

我们的技能并不是固定不变的，你可以擅长很多事情，也可以选择做任何事情。对于那些要求你承担超出公平份额且无法晋升的工作，要敢于拒绝，把你的精力投入到你真正想要做的事情上。

长按扫码关注