不善言辞的程序员，如何「向上管理」？

如果第二次看到我的文章，欢迎「文末」扫码订阅我个人的公众号（跨界架构师）哟~

每周五11：45 按时送达。当然了，也会时不时加个餐～

我的第「114」篇原创敬上

大家好，我是Z哥。

不知道你是否觉得自己怀才不遇，遇不到一个赏识你的人呢？

又或者觉得一件事情自己已经很努力去做了，但还是无法满足上级的要求。

类似的这些情况在不善言辞的程序员群体中，尤其地常见。

如果我们找不到方式来主动改善这个问题，那就只能听天由命了。看是不是恰巧天上掉一个“伯乐”下来看到你这匹“千里马”。

当我们初入职场的时候，可能对这一点的感知不是很强烈。

那是因为当时你还是一个行业的新手，有很多知识层面的渴求，仅凭这个动力源就能推动你往前走。

但是，当你一旦进入到知识积累的「平台期」，对我们大部分人来说，如果你不在BAT之类的巨头，缺乏了业务难度上的挑战，唯一剩下的动力源就是他人对你的认可了，特别是上级对你的认可。

否则你就要忍受未来更长期的一段苦闷期，“成就感”将会与你渐行渐远。

可能很多人认为「向上管理」中，paimapi占了大部分。

我想每个人曾经都或多或少有过类似的想法，Z哥我自己也不例外（无奈～）。内心戏大概是这样的：

我这个人很直接的，才不会拍领导马屁。

跟领导走的太近不太好吧，别人会怎么看我。

没有本事的人才整天围着领导转。

其实有这样想法的人只是看到了一个表象。领导之所以能成为你的上级，自然不傻，脑子是很清楚的，单凭paimapi并不会对你的仕途带来多大的变化。

如果真的靠paimapi能上位，那这个企业的发展前景也不会太乐观，毕竟大家的精力都用到paimapi上去了，事情谁来干？

不过，虽然很多人并不会去paimapi，但是容易走到另一个极端：为了证明自己是不屑于献媚领导的人，所以经常直言不讳，甚至非得在观点、方案的优劣高低上争出个胜负，最后闹得大家都不愉快。不知道你身边有这样的例子发生吗？

另外，一听到「管理」这个词，大多数人脑子里第一浮现出来的后一个词是「员工」或者「下属」，也就是「管理员工」或者「管理下属」。

我们很自然的将一对多关系中的“一”套到「管理」这个词上。认为，「管理」是用于“向下”的，而不是“向上”。

其实我觉得恰恰相反。

陈春花教授有一个经典的解读：

向上才需要管理，向下更应该是负责。

——陈春花：管理者要学会向下负责

我对此的理解是，「向下负责」本质就是对人的负责，对公司资源利用的负责。从因果关系来说，如果能对下做好负责，作为管理者本身的绩效自然也不会太差，所以并不需要刻意的向上表露出你有那么的“负责”这种浮于表象的状态。

反而「管理」是要向上的。因为「管理」相比「负责」更具调控色彩，显得更“柔”，而「负责」则更“刚”一些。我们具体去执行做一件事才需要“刚”，要达到使命必达的效果。但是与上级的关系处理上，如果“刚”的话，自然矛盾多多，所以更需要“柔”一些的「管理」。

那么应该怎么考虑呢？

我觉得这事应该以现代社会的「分工协作」这个角度来考虑。

从这个角度上来看，不管对方是上级还是下级，本质上都是在与人协作。任何一个人必然有长短、优劣，所以这个事情就变成了一个如何「扬长补短」的事情。做好这个事情分为三步。

01  构建上级的“用户画像”

你要第一件做的事就是想办法把握各种机会和途径，搞清楚「你的上级是一位怎样的人？」。

这个就像CRM系统中的「用户画像」概念，你要慢慢地把你上级的一些特点打上标签，逐渐形成一个清晰的、有血有肉的形象。

比如以下这些问题。

沟通风格。喜欢看文字报告还是喜欢当面聊？

管理风格。授权型还是掌控型？

做事风格。注重大局还是扣细节？

性格。有哪些明显的性格特点？

擅长什么？

他现在面临哪些压力？

他的底线/原则是什么？

他的关系链有哪些？与哪些人的信任度较高，哪些较低？

……

如果公司有统一的性格测试之类测试报告，如DSCI等，同时你有机会获知的话，可以更快的完成这件事情。

另外，你也可以多关注你上级的做的那些「高频」的事和说的那些「高频」的话。

02  扬长

相对来说，一个人的长处相比短处更容易被人发现和识别。并且一个人的长处才是他的立足之本。所以，我们优先要考虑的就是如何去「扬长」。

分工协作的本质也就是拿你的长处去与别人的长处去做交换，弥补各自的短处。

比如，你会做写程序，但是不会卖东西；而销售会卖东西，不会写程序。那么你就把程序交换给销售去用，让他可以卖的更多，然后销售赚的钱和你一起分。

另外，上级的长处对你来说其实就是一种资源，很多人看不到这一层价值，宁愿自己埋头苦干。

比如，他的信息渠道比你广，除了信息量比你大之外，认知能力大概率也比你高。所以很多时候如果能多去请教一下，可以少走很多弯路。（当然不是拿来主义的请教，带着自己的思考结果去）

所以，充分利用好你上级的长处，对你做事有事半功倍的效果。

03  补短

这里有一个很容易陷入的误区，认为做下属的就应该服从领导的安排。其实「服从」不等于「盲从」，因为每个人都存在短板之处。

也正因为是这样，所以上级在某些短板的方面对事物的理解和判断总是偏颇的。这个时候其实你不能放任上级的不切实际的想法，而要去补上这个“短板的缺口”。

比如说，你的上级是做测试出身的，这时候你作为一位开发人员，应该在软件架构、技术选型上给出可维护性、性能、成熟度等等方面的意见，而不是上级说用哪个就用哪个。

做好「补短」除了发挥自己的长处、专业性之外，前提是做好一件事——「主动沟通」。这很重要，通过沟通让你的“长板”与你上级的“短板”做一次对齐。

否则你可以想象一下，上级对你的期望其实是你所认为的300%，你怎么努力做到120%都无法让他满意。长期以往，你上级对你就会贴上不靠谱的标签，而你又是哑巴吃黄连，有苦说不出。最终的出路唯有分道扬镳。

并且，沟通其实也是在上级面前树立你在自己领域内专业度的机会。

思路清楚了，具体该怎么做呢？下面举几个常见的场景来说说。

01  接收需求/任务

这个场景每个人都遇到，甚至是天天在发生，因为这件事中你是被动方。

但是有不少人可能接任务的“姿势”并不对。他们会认为，这有什么难的，上级让做啥，就做啥。

虽然工作一两年之后我们已经摆脱了初入职场时的需要手把手教的阶段，但这种思想也还是一种很稚嫩的职场思维。

因为很多时候上级传递对信息可能是不完整的，或者是没清楚的，甚至是错的。

如果你每次来啥接啥，那你大概率会忙的焦头烂额（其实有一些996是可以避免的）。最终还会失去上级对你的信任，认为你不靠谱。

所以，接收任务的时候，你先得做出判断。最常见的是下面3个问题。

1.这个任务需要往大了考虑还是往小了考虑？

比如说，上级让你找一个MQ的中间件来用。有的人会花很多时间整理一份具体的某MQ实施方案出来；有的人则是整理一份多个MQ中间件的优缺点以及与当下实际场景的契合度的文档。前者就是往小了考虑，后者就是往大了考虑。

如果你不做这个判断，那你有50%的可能性做的是不符合上级预期的。

2.是真的要做？还是只是试探一下你？

一般来说，如果一件事你觉得很大，但是上级又没明显给你足够的资源，甚至是连打算给你多少资源都没说的话，基本就能判断这是一件试探性的事情。此时，上级并不确定这件事值不值得去做。

这个时候比较稳妥的方式是，你花尽可能小的成本去帮他完成这个“试探”。

比如，上级和你说：“我看现在大家都在推行Docker，运维效率和扩容速度都能有明显的提高，我们也用起来吧”。这个时候他没说给你多少时间、多少人力去做这个事情，哪怕你真的想去推进这个事情都不一定推的动。

此时你应该找一个与你关系最好的团队中的最边缘的业务去尝试用起来。这样的话，你既交了差，毕竟这个事你去做了嘛。而且还能得到一个实际的真实情况，帮助上级完成了这个“试探”的事情，毕竟网上的文章写的事情并不一定与你实际情况相符。后续是否继续开展就是另一回事了。

当然，有些事可能很大，大到无法小规模试运行。这个时候你尽量去找一些案例型的文章，将这些案例中反映出来的问题收集起来，毕竟案例是非常具体的，不太可能是作假、吹牛，甚至其中有一些知名公司做背书，结论的说服力就更强了。

3.任务已经很重了，任务怎么接？

这个时候一定不要勉强接下，很多没必要的996就是这么产生的。

诚恳地说清楚自己手头有哪些事，如果要接这个任务的话，是否有什么任务的安排要顺延。

很多人怕说自己接不了任务，觉得会降低上次对自己能力的评价。其实只要是诚恳的沟通，有理有据，凡是一个明理的上级肯定会接受的。甚至反而会对你的条理性、做事有主次印象深刻。

哪怕最终由于特殊的重要性，还是强压下来做了，那么至少在未来给你的任务安排上会更克制一些。毕竟你已经明确的给他了一个反馈，告诉了他自己的负荷上限在哪。

第一个场景写的有点长，因为这的确对每个人都很常见。但是后续一些偏主动的事情可能有不少人从未考虑去做。

02  工作汇报

不管是对接收的需求/任务的汇报，还是由自己发起的汇报。本质上就是一个「如何更快更准的将你的信息传递给对方」的过程，当然还可以顺带寻求一下建议。

这里面体现了对上级两个资源的利用，「时间」和「信息」。

很多人在汇报的时候，内容视角是“自己”而不是“对方”。啪啦啪啦只注重自己要说什么，而不是注重对方想听什么？需要听什么？

但是要做好这一点，取决于在你这里上级的「用户画像」是否完整，没有其它的办法。

不过汇报的内容还是有一些技巧可循的，我建议的是，使用「总-分」或者「总-分-总」的语言组织形式。

结论先行可以确保后续的内容有一根“总线”给拉着，不至于让对方听到哪思维就被带到哪，没有重点，不知道你在说什么。本质上也是在做「目标对齐」。

大致是这样的结构：

总（what）：这是一件什么事。需要你（上级）做什么。

分：事情的来龙去脉（why），或者分门别类讲一下细节（how）。

这个比较好理解，就不展开了。只是在聊「分」的时候注重一些层次感，要尽量符合线性思维，循序渐进，不要跳来跳去。

03  争取资源

资源有两种获得方式。一种是你的价值已经被人认可，主动给你资源。另外一种是还未被认可，需要自己主动去争取资源。这里聊的是第二种情况。（与世无争的不在讨论范围内）

很多人对于争取资源有一些误区，在你的价值还未被认可的时候，其实你提供再多过去的成绩，也只能算是锦上添花。相比之下，更重要的是你要阐述获得这些资源之后你可以带来什么？

比如最常见的，你希望能升职加薪，啪啦啪啦说了一堆自己做了哪些成绩，最后来一句，所以我想涨薪XX，能升职XX。

从形态上，这是一种相互对立的关系。

假如你这么说，我希望在新的一年可以加薪XX、能升职到XX。升职之后我有了更多的资源和发挥空间，可以做XX、XX事情，这些事情可以带来XX、XX的效益、价值，所以我值得获得加薪XX。（这也是总-分的内容结构）

从形态上，这是一种并肩作战的关系。

如果你是上级，你觉得哪个更容易打动你？

我们这一辈人想像上一辈那样在一家企业呆到退休的可能性越来越低了。

想要在整个行业、社会上更容易立足，就需要不断做出更大的成绩。而这些都离不开资源的支持。

你的上级是每个人最近在咫尺的资源，所以，做好「向上管理」是每个人提高自我价值、更好地在社会立足的关键第一步。

人性是趋利避害的，我们总是想付出更少收获更多。但是如果你的上级绩效没做好，总的资源包就没多少，自然分下来也就没多少。所以，你团队的绩效、甚至是你的绩效都取决于你上级的绩效，你首先得帮助他成功。

一旦你成了他的得力助手，就相当于你抢占了他身边的一个「生态位」。只要他在，你就在。很多人都在寻求的不可替代性就自然而然形成了。

生态位：描述了一个物种在其群落生境中的功能作用，它是一个物种为求生存而所需的广义“资源”。

——维基百科

比如，树需要阳光和水才能生长，这里阳光和水便占了两个围绕树的生态位，缺一不可。

好了，我们总结一下。

这篇呢，Z哥先分享了一个我的观点。在工作上获得认可对你的职业道路健康发展很重要，而想要获得认可，做好「向上管理」很重要。

然后阐述了普遍的两个误区。「向上管理就是怕马屁」，或者「不需要向上管理，向下才需要管理」。

其实我们应该以「分工协作」的角度来考虑这个问题。搞清楚上级的「用户画像」，然后「扬长避短」。

最后分享了三个工作中常见的场景应该如何进行「向上管理」。

希望对你有所启发。

不管怎样，希望每个人至少都能找到你的「生态位」。当然，能够“被向上管理”就更好了。

推荐阅读：

认知的高度 = 人生的高度

大家在寻找的高级程序员到底是什么样子的？

出处：https://zacharyfan.com/archives/977.html

如果你喜欢这篇文章，可以点一下左下角的「大拇指」。

这样可以给我一点反馈。: )

谢谢你的举手之劳。

如果你是初级程序员，想提升但不知道如何下手。又或者做程序员多年，陷入了一些瓶颈想拓宽一下视野。欢迎关注我的公众号「跨界架构师」，回复「技术」，送你一份我长期收集和整理的思维导图。

如果你是运营，面对不断变化的市场束手无策。又或者想了解主流的运营策略，以丰富自己的“仓库”。欢迎关注我的公众号「跨界架构师」，回复「运营」，送你一份我长期收集和整理的思维导图。

定期发表原创内容：架构设计丨分布式系统丨产品丨运营丨一些深度思考。

软件开发

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。