最近研究了一下向上管理，写了一篇文章在这里分享一下

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

这是一个创建于 501 天前的主题，其中的信息可能已经有所发展或是发生改变。

从几年前就一直听同事提起向上管理，最近感觉工作中遇到了很多问题都和它有关，就去研究了一下，整理成了一篇文章。原文在这里浅谈如何向上管理

最近听说了很多事，加之目前自己也处在被汇报以及需要向上汇报的状态中间，迫使我开始思考向上管理（ managing up ）这个话题。这是一个有争议的话题，很多人（包括曾经的自己）下意识的会将向上管理与徒有其表的讨好或者迎合这类负面词划上等号。借此契机在查阅了很多资料之后，才意识到它不过是一项职场软技能而已。

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

A 同学在 Tech Lead 毫不知情的情况下向客户承诺了一个交付日期
B 同学选择将一个他认为毫无紧要的 bug 留到第二天再修，未料想该 bug 阻碍了大堆功能的后续测试，拖慢了上线进度
C 同学人生信条万事不求人，卡在一个技术难题上两天两夜了，并且决定继续死磕到底

如果你一时不太理解这几个事例和向上管理的联系是什么，没关系我会在后文一一道来

首先需要澄清的是，这里所说的“向上”针对的是大部分常规情况（ average ）——什么是“大部分常规情况”？说白了就是你依然有意愿和你的老板（本文中代指所有你可能汇报的对象）进行沟通。我反对用“人无完人”的圣母论调否认坏老板的存在，把工作中的摩擦都归咎于自己。只不过有时候你需要区分坏老板和压力中的老板两类不同人群。

广义上的向上管理可以涵盖上下级间的种种事务，所以在哈佛商业评论网站里向上管理的标签下，你会看到诸如“如何与不称职的上级相处”，“如何给你的上级提出反馈”等等内容。从这些文章里你会学到针对每一类情况应该采用什么样的策略来应对。但本文并不是另一篇职场危机的化解指南，因为在我看来对症下药解决的功效实在有限。总会有前人无法预见的问题出现，总有问题需要你独自解决，如果你清楚的知道问题背后的问题是什么，处理起来会更得心应手。本文想讨论的便是向上管理背后的出发点，以及有哪些普适原则是可以参考的

我想我们都同意，向上管理的目的是为我们赢得更多职场上的机会，这里的机会包括但不限于你想做的事情、扩充你的团队、你想要的职位等等。之所以想明确指出这一点，是因为当我在查阅有关向上管理资料的时候，有很多其他目标也被提出，比如为了让你工作更加顺利，为了影响上级对你的感观，为了维护和上级间的积极关系等等。但是在我看来这些更像是手段，或者阶段性里程碑：难道你付出了种种努力只是为了营造一个完美人设吗？不，终有一天你需要将它兑换成职场资源。

也就是说当我们在谈论向上管理的时候，大部分时候谈论的是方式方法，但各式各样的方式方法又难免让我们落入到按照具体情况具体分析的圈套中——于是我才把本篇的内容限定在“入门”这个范畴内，我想我们可以找到一些易操作的低成本手段解决尽可能广的问题。

前提

向上管理的根基是沟通，这点我必须要首先强调出来。大部分工程师似乎自带一类认知：我只需要默默把工作做好，然后用结果和成绩来替我说话就好了——很可惜这类想法已经无法完全适应当下。

首先从个体出发，那类程序员拿到需求之后埋头苦干一个月然后上线的开发模式早就不复存在了。一方面我们看到项目开发中分工倾向于细化和专业化；另一方面之方面市场瞬息万变要求团队快速响应。两者看似不相及，但背后都指向了对同一技能的高要求——沟通。如果你无法准确通过沟通及时了解到需求变化，如果你无法通过沟通了解到目前工作的阻碍在哪，如果你无法通过沟通了解到你需要联络谁来进行推进下一步工作，你的工作则无法完成。有效的沟通能够帮助你从 0 到 1 完成工作，而向上管理则是锦上添花。如果你连沟通的意愿都没有，向上管理则无从谈起。

回到本文开头的例子，为什么同学 B 会认为他负责的 bug 可以被推迟修复，本质上是因为他对 bug 的影响面和优先级理解产生了偏差。解决这类问题最好的办法是好奇心，在我看来这也是向上管理的核心。

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

理解你的工作

再比如我们再看看 C 同学的例子，他对于工作内容的理解过于纯粹了：我只需要把代码写好即可。

“代码需要写的多好？”，“代码需要写的多快？”这是两个需要想通的最根本问题。我理解每个程序员都希望成为能够细心雕琢代码的工匠，并且讨厌被当作螺丝钉，但很抱歉在面对跑马圈地的互联网的竞争的时候，绝大部分时候快比好更重要。我并不是说交付相关和非交付相关就一定是二元对立的，对程序员成长有益的技术难题就必须被牺牲掉。我们可以采用更灵活的方式处理这类问题：比如采用其他技术方案绕过问题来优先保证上线，然后再争取更多的资源来回过头解决这个问题。我的经验是“时间”是解决“难题”的最大敌人，在 StackOverflow 上提问，向 GitHub 提 issue ，做 demo 验证你的猜想都是长线工作。

值得一提的是 C 同学的反面也并不少见，想象一位 D 同学被公认为团队里的好好先生，任何人有问题第一时间会想到他，他也有求必应。很可能他一天的工作下来的结果是帮助大伙解决了不计其数的难题，但是自己的代码丝毫没有进展只能晚上加班写。同学 C 和同学 E 身处不同的场景但是都犯下了同样的错误。

你的工作绝不会仅限于代码，一定还包括解决方案，技术选型，以及汇报等等。这些任务最终结果的好坏取决于你对任务背后问题理解深刻与否，甚至取决于你对提出问题的人的理解深刻与否：方案针对的业务问题是什么？汇报对象想听的是什么？我曾经听说有人提出过工程师是否需要了解业务的疑问——提出这种问题的人不是蠢就是坏：业务是问题目的技术是达到目的的手段，如果你对目的都还不清楚如何选择手段。还有一类对理解工作带来的益处常常被忽略：有助于你在更大范围内推进工作。和人打交道的工作比代码更难，但无法避免。因为在大规模协作无处不在的今天，你的工作大概率需要依赖他人来完成。如果你需要的后端资源迟迟不到位，甚至不配合怎么办？你应该联络谁，在说服他的过程中应该给出什么样的理由，也依赖你在项目中的上下文。

截至目前我还都是在讨论「我」，至于「我」和「向上」的关系，则是我下面要聊的内容

理解老板/客户的工作

我们时常需要解决高优先级的线上问题，这类问题需要我们 24×7 小时工作在上面直到修复完成。因为问题对业务的影响面巨大所以各方都非常关切，客户或者项目经理会不停的询问你进展细节。对于正在一线解决问题的工程师来说，因为这不仅在打断工作节奏，还对解决问题毫无帮助。

如果我们换一个视角看待问题，事情也许就说的通了：确保功能稳定是他们的工作职责，他们也有自己要负责的甲方。但吊诡的地方就在于，通常对于此类非技术人员来说，他们承担着更重大的责任，能做的却微乎其微，这可能是他们介入问题的唯一方式。所以你不能简单粗暴的告诉他们别管了来单方面的解决你的困恼，问题矛盾在于我们既要保证他们的工作职责得以履行，也要保证以工程师工作不被打搅，通常缓和此类问题的恰当方式是，工程师可以定时向上更新工作进度，尤其是在取得重大突破的时。

工作中的“不对称性”时常被我们忽略：我们会因为视频会议另一端的某个人每天在同一个会议上出现，以为我们共同承担同一份工作职责。并由此产生抱怨：“为什么他没有参加今天的站会？”，“为什么我们发给他的邮件他还没有回复？”——因为我们完全不知道对方所处的商业机器是如何运作的，我们只不过一厢情愿的在给自己的优先级打分。我们完全没有意识到我们打交道的虽然只是一个人，但他可能代表的是一个组织，在一些我们认为“匪夷所思”的决策上，可能他只不过是意志的传声筒而已。

拉回身边，例如你认为你所在团队 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 (Individual Contributor) 轻松。enigneer 要给自己找方向，需要验证自己的方向是大方向。领导最大的工作，就是保持下面 enigneer 的工作动力。

我的 manager 在这里工作多年，我会告诉他我想做什么。他会告诉你一些个人看法，告诉你他觉得这个方向怎么样，指点一下。如果他觉得合理，他就会说你去做。他觉得不合理，会再给你一个方向，让你去想一想。但如果你轮到别人给你方向，这可能不是个好方向。Meta 的哲学是，你自己找的方向会有动力去做，等别人给你方向你就会随便做做，那对你自己不好。