最近传闻了许多事，加之现在自己也处在被报告以及需求向上报告的状态中间，迫使我开端考虑向上办理（managing up）这个论题。这是一个有争议的论题，许多人（包含从前的自己）下意识的会将向上办理与徒有其表的巴结或许迎合这类负面词划上等号。借此契机在查阅了许多资料之后，才意识到它不过是一项职场软技能罢了。

先从这些作业开端说起，有些发生在我身上，有些是我听来的，有些发生在很久以前：

  • A 同学在 Tech Lead 毫不知情的状况下向客户许诺了一个交给日期
  • B 同学选择将一个他认为毫无重要的 bug 留到第二天再修，未料想该 bug 阻止了大堆功用的后续测试，拖慢了上线进度
  • C 同学人生信条万事不求人，卡在一个技能难题上两天两夜了，而且决议持续死磕究竟

假如你一时不太了解这几个案例和向上办理的联络是什么，不要紧我会在后文一一道来

首先需求澄清的是，这儿所说的“向上”针对的是大部分惯例状况（average）——什么是“大部分惯例状况”？说白了便是你仍然有志愿和你的老板（本文中代指一切你或许报告的目标）进行交流。我反对用“人无完人”的圣母论调否认坏老板的存在，把作业中的冲突都归咎于自己。只不过有时分你需求区分坏老板和压力中的老板两类不同人群。

广义上的向上办理能够包含上下级间的种种事务，所以在哈佛商业评论网站里向上办理的标签下，你会看到诸如“怎么与不称职的上级共处”，“怎么给你的上级提出反应”等等内容。从这些文章里你会学到针对每一类状况应该采用什么样的战略来应对。但本文并不是另一篇职场危机的化解攻略，由于在我看来对症下药处理的成效实在有限。总会有前人无法预见的问题呈现，总有问题需求你单独处理，假如你清楚的知道问题背面的问题是什么，处理起来会更称心如意。本文想评论的便是向上办理背面的出发点，以及有哪些普适准则是能够参阅的

我想咱们都赞同，向上办理的意图是为咱们赢得更多职场上的时机，这儿的时机包含但不限于你想做的作业、扩充你的团队、你想要的职位等等。之所以想明确指出这一点，是由于当我在查阅有关向上办理资料的时分，有许多其他方针也被提出，比方为了让你作业愈加顺利，为了影响上级对你的感观，为了保护和上级间的积极联系等等。可是在我看来这些更像是手法，或许阶段性里程碑：难道你付出了种种努力仅仅为了营造一个完美人设吗？不，终有一天你需求将它兑换成职场资源。

也便是说当咱们在议论向上办理的时分，大部分时分议论的是方法方法，但林林总总的方法方法又难免让咱们落入到依照具体状况具体分析的圈套中——所以我才把本篇的内容限定在“入门”这个范畴内，我想咱们能够找到一些易操作的低成本手法处理尽或许广的问题。

前提

向上办理的根基的交流，这点我必须要首先着重出来。大部分工程师好像自带一类认知：我只需求默默把作业做好，然后用成果和成绩来替我说话就好了——很可惜这类主意现已无法彻底适应当下。

首先从个体出发，那类程序员拿到需求之后埋头苦干一个月然后上线的开发形式早就不复存在了。一方面咱们看到项目开发中分工倾向于细化和专业化；另一方面之方面商场瞬息万变要求团队快速呼应。两者看似不相及，但背面都指向了对同一技能的高要求——交流。假如你无法精确经过交流及时了解到需求改变，假如你无法经过交流了解到现在作业的阻止在哪，假如你无法经过交流了解到你需求联络谁来进行推动下一步作业，你的作业则无法完结。有效的交流能够协助你从0到1完结作业，而向上办理则是锦上添花。假如你连交流的志愿都没有，向上办理则无从谈起。

回到本文开头的比方，为什么同学 B会认为他担任的 bug能够被推迟修正，本质上是由于他对 bug的影响面和优先级了解产生了偏差。处理这类问题最好的方法是好奇心，在我看来这也是向上办理的核心。

请保持好奇心去了解你作业的全貌，了解你老板的作业，了解你客户的作业。尽管这儿“了解”这个单词被不断重复，但好奇心才是要点，它是你推动一切问题的核心。

了解你的作业

再比方咱们再看看 C 同学的比方，他关于作业内容的了解过于纯粹了：我只需求把代码写好即可。

“代码需求写的多好？”，“代码需求写的多快？”这是两个需求想通的最根本问题。我了解每个程序员都期望成为能够细心雕琢代码的工匠，而且讨厌被当作螺丝钉，但很抱愧在面对跑马圈地的互联网的竞赛的时分，绝大部分时分快比好更重要。我并不是说交给相关和非交给相关就必定是二元敌对的，对程序员生长有益的技能难题就必须被牺牲掉。咱们能够采用更灵敏的方法处理这类问题：比方采用其他技能计划绕过问题来优先确保上线，然后再争夺更多的资源来回过头处理这个问题。我的经验是“时刻”是处理“难题”的最大敌人，在 StackOverflow 上发问，向 GitHub 提 issue，做 demo 验证你的猜测都是长线作业。

值得一提的是 C同学的不和也并不罕见，幻想一位 D 同学被公认为团队里的好好先生，任何人有问题第一时刻会想到他，他也有求必应。很或许他一天的作业下来的成果是协助大伙处理了不计其数的难题，可是自己的代码丝毫没有发展只能晚上加班写。同学 C和同学 E身处不同的场景可是都犯下了同样的过错。

你的作业绝不会仅限于代码，必定还包含处理计划，技能选型，以及报告等等。这些使命终究成果的好坏取决于你对使命背面问题了解深入与否，乃至取决于你对提出问题的人的了解深入与否：计划针对的事务问题是什么？报告目标想听的是什么？我从前传闻有人提出过工程师是否需求了解事务的疑问——提出这种问题的人不是蠢便是坏：事务是问题意图技能是达到意图的手法，假如你对意图都还不清楚怎么选择手法。还有一类对了解作业带来的好处常常被忽略：有助于你在更大范围内推动作业。和人打交道的作业比代码更难，但无法防止。由于在大规模协作无处不在的今日，你的作业大概率需求依赖他人来完结。假如你需求的后端资源迟迟不到位，乃至不配合怎么办？你应该联络谁，在压服他的过程中应该给出什么样的理由，也依赖你在项目中的上下文。

到现在我还都是在评论「我」，至于「我」和「向上」的联系，则是我下面要聊的内容

了解老板/客户的作业

咱们经常需求处理高优先级的线上问题，这类问题需求咱们 247 小时作业在上面直到修正完结。由于问题对事务的影响面巨大所以各方都十分关心，客户或许项目司理会不断的问询你发展细节。关于正在一线处理问题的工程师来说，由于这不仅在打断作业节奏，还对处理问题毫无协助。

假如咱们换一个视角看待问题，作业也许就说的通了：确保功用稳定是他们的作业职责，他们也有自己要担任的甲方。但吊诡的地方就在于，一般关于此类非技能人员来说，他们承当着更严重的职责，能做的却微乎其微，这或许是他们介入问题的仅有方法。所以你不能简略粗犷的告知他们别管了来单方面的处理你的困恼，问题矛盾在于咱们既要确保他们的作业职责得以履行，也要确保以工程师作业不被打搅，一般缓和此类问题的恰当方法是，工程师能够守时向上更新作业进度，尤其是在取得严重突破的时。

作业中的“不对称性”经常被咱们忽略：咱们会由于视频会议另一端的某个人每天在同一个会议上呈现，认为咱们共同承当同一份作业职责。并由此产生诉苦：“为什么他没有参与今日的站会？”，“为什么咱们发给他的邮件他还没有回复？”——由于咱们彻底不知道对方所处的商业机器是怎么运作的，咱们只不过一厢情愿的在给自己的优先级打分。咱们彻底没有意识到咱们打交道的尽管仅仅一个人，但他或许代表的是一个组织，在一些咱们认为“匪夷所思”的决议计划上，或许他只不过是毅力的传声筒罢了。

拉回身边，例如你认为你地点团队 Tech Lead的职责是什么？我没法告知你它是什么，可是我能够告知你它不是什么：假如 Tech Lead每天100%的时刻都在和你做一模一样的事，那他必定不是称职的 Tech Lead。这种认知的转变是十分重要，当你意识到他的作业中心并不在你身上，乃至不在代码上，这会迫使你开端考虑你和上级的合作以及交流形式。假如他无法随叫随到，无法第一时刻呼应你提出的问题，那你需求想方法不要让他成为你作业的单点依赖。

我在前一篇文章《关于时刻办理的一点主张》里，提到了一类司理常常陷入的反形式：来者不拒的处理部属提出来的一切问题。正确的做法是，司理能够供给主张，能够商讨后续能够采纳的行动，但问题应该终究归还给部属自己独立处理。为了达到这个方针，需求在团队内明确主动性，鼓励团队成员采纳尽或许高的主动性，制止低主动性。主动性从低到高能够分为5类：

  • 等着被告知要做什么（主动性最低）
  • 主动问询我要做什么
  • 主张应该做些什么，而且采纳相应行动
  • 直接行动起来，而且给出自己的主张
  • 单独行动起来，定期进行报告（主动性最高）

所以关于司理来说最理想的团队作业形式是，团队内的成员主动去发现问题而且处理问题。再说的再直接一些，咱们应该尽或许减少上级的作业量而不是添加他们的作业量。假如上级每天都在担心你的作业，乃至刻不容缓想替你完结手头上的作业，这对咱们都不是好事。这一切的前提便是上一小节着重的，你需求清楚的知道你要做什么。我想不少人传闻过一个类似职场技巧：提出问题时同时也给出处理计划，或许至少能够迈出去的第一步——它背面的原理便是如此。

你或许会问，假如在寻求上级定见之前提出的计划是错的怎么办？果真如此的话，我会把它当作一个对齐你我之间主意的时机。说实话我作为 Tech Lead最担心的便是，当我在给团队成员讲解需求或许计划后，没有任何人提出任何问题。有不合、有偏差、有不赞同见很正常，共同的沉默让人惧怕。

在 2019 年的 QCon 大会上，曾任 Etsy CTO 的 Kellan Elliott-McCrea 进行了一次有关向上办理的共享 Getting Real about Managing up，在这次演讲中，他对向上办理进行了如下定义，即向上办理其实是让你的上级更好的协助你把作业做好。：

……I’m going to shift some of that load to you. You’re welcome, you’ve been deputized. Good news, it means I’m giving you some control over your destiny……what we mean by managing up is making it easier for your manager to support you in doing great work. That’s our definition of managing up

我对此十分赞同，想方法让咱们自己做好主角，让上级做好的副角就够了。

你想知道向上办理“落地”是什么姿态的？前几天刚好在极客公园一篇关于 Meta裁人的报道里（《Meta万人裁人亲历者自述：小扎尝到了降本的甜头》）看到了 Meta里是怎么做向上办理的

Meta的特别之处是员工十分善于向上办理，做 manager好像比 IC (IndividualContributor)轻松。enigneer要给自己找方向，需求验证自己的方向是大方向。领导最大的作业，便是保持下面 enigneer的作业动力。

我的 manager在这儿作业多年，我会告知他我想做什么。他会告知你一些个人观念，告知你他觉得这个方向怎么样，指点一下。假如他觉得合理，他就会说你去做。他觉得不合理，会再给你一个方向，让你去想一想。但假如你轮到他人给你方向，这或许不是个好方向。Meta的哲学是，你自己找的方向会有动力去做，等他人给你方向你就会随便做做，那对你自己欠好。

结束语

咱们究竟在处理什么问题？

在东东枪教师的播客《宇宙牌电饭锅》里，他提出了这样的一个观念：

咱们讲甲方乙方……不论你做乙方是做什么事务，广告也好，咨询也好，乃至是教师也好，你认为帮他处理了一个商业问题，你认为帮他处理的是一个需求专业技能的问题……你处理的是他个人在职场上，在他的职位上要面对的一个难题，而且你的处理方法许多其实是情感式的，你让他自傲了，你让他安心了。

这是十分厉害的洞见，他供给了一种彻底不同的视角看待你的作业：你认为你本质上供给的是专业技能，但实际上你带来的是心思安慰。考虑到咱们每个人本质上都是在以乙方人物在作业，仔细想想，你很难说他是错的。

至于高级技巧，有时机今后再聊

你或许会喜爱

  • 程序员怎么生长
  • 上一年我是怎么处理团队问题的
  • 测试覆盖率治欠好你的精神内耗
  • 昂贵的质量
  • 了解流程
  • 协助团队生长是仅有的出路
  • 开源社区的暗面
  • 上一年做 Tech Leader 犯过最大的错
  • 技能写作的困境
  • 拥抱准则与面对现实
  • 代码与质量的考虑与漫笔
  • 从对 Vue 中 mixin 的批评，到对模块间依赖联系的探讨