不善言辭的程式設計師,如何「向上管理」?

huorongbj發表於2019-11-08

如果第二次看到我的文章,歡迎「文末」掃碼訂閱我個人的公眾號(跨界架構師)喲~ 

每週五11:45 按時送達。 當然了,也會時不時加個餐~

我的第「114」篇原創敬上

 

大家好,我是Z哥。

 

不知道你是否覺得自己懷才不遇,遇不到一個賞識你的人呢?

 

又或者覺得一件事情自己已經很努力去做了,但還是無法滿足上級的要求。

 

類似的這些情況在不善言辭的程式設計師群體中,尤其地常見。

 

如果我們找不到方式來主動改善這個問題,那就只能聽天由命了。看是不是恰巧天上掉一個“伯樂”下來看到你這匹“千里馬”。

 

 

當我們初入職場的時候,可能對這一點的感知不是很強烈。

 

那是因為當時你還是一個行業的新手,有很多知識層面的渴求,僅憑這個動力源就能推動你往前走。

 

但是,當你一旦進入到知識積累的「平臺期」,對我們大部分人來說,如果你不在BAT之類的巨頭,缺乏了業務難度上的挑戰,唯一剩下的動力源就是他人對你的認可了,特別是上級對你的認可。

 

否則你就要忍受未來更長期的一段苦悶期,“成就感”將會與你漸行漸遠。

 

 

可能很多人認為「向上管理」中,拍馬屁佔了大部分。

 

我想每個人曾經都或多或少有過類似的想法,Z哥我自己也不例外(無奈~)。內心戲大概是這樣的:

 

  • 我這個人很直接的,才不會拍領導馬屁。

     

  • 跟領導走的太近不太好吧,別人會怎麼看我。

     

  • 沒有本事的人才整天圍著領導轉。

 

其實有這樣想法的人只是看到了一個表象。領導之所以能成為你的上級,自然不傻,腦子是很清楚的,單憑拍馬屁並不會對你的仕途帶來多大的變化。

 

如果真的靠拍馬屁能上位,那這個企業的發展前景也不會太樂觀,畢竟大家的精力都用到拍馬屁上去了,事情誰來幹?

 

不過,雖然很多人並不會去拍馬屁,但是容易走到另一個極端: 為了證明自己是不屑於獻媚領導的人,所以經常直言不諱 ,甚至非得在觀點、方案的優劣高低上爭出個勝負,最後鬧得大家都不愉快。不知道你身邊有這樣的例子發生嗎?

 

 

另外,一聽到「管理」這個詞,大多數人腦子裡第一浮現出來的後一個詞是「員工」或者「下屬」,也就是「管理員工」或者「管理下屬」。

 

我們很自然的將一對多關係中的“一”套到「管理」這個詞上。認為,「管理」是用於“向下”的,而不是“向上”。

 

其實我覺得恰恰相反。

 

陳春花教授有一個經典的解讀:

 

向上才需要管理,向下更應該是負責。

——陳春花:管理者要學會向下負責

 

我對此的理解是,「向下負責」本質就是對人的負責,對公司資源利用的負責。從因果關係來說,如果能對下做好負責,作為管理者本身的績效自然也不會太差,所以並不需要刻意的向上表露出你有那麼的“負責”這種浮於表象的狀態。

 

反而「管理」是要向上的。 因為「管理」相比「負責」更具調控色彩,顯得更“柔”,而「負責」則更“剛”一些。我們具體去執行做一件事才需要“剛”,要達到使命必達的效果。但是與上級的關係處理上,如果“剛”的話,自然矛盾多多,所以更需要“柔”一些的「管理」。

 

 

那麼應該怎麼考慮呢?

 

我覺得這事應該以現代社會的「分工協作」這個角度來考慮。

 

從這個角度上來看, 不管對方是上級還是下級,本質上都是在與人協作。任何一個人必然有長短、優劣,所以這個事情就變成了一個如何「揚長補短」的事情。做好這個事情分為三步。

 

 

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哥先分享了一個我的觀點。 在工作上獲得認可對你的職業道路健康發展很重要,而想要獲得認可,做好「向上管理」很重要

 

然後闡述了普遍的兩個誤區。「向上管理就是怕馬屁」,或者「不需要向上管理,向下才需要管理」。

 

其實我們應該以「 分工協作」的角度來考慮這個問題。 搞清楚上級的「使用者畫像」,然後「揚長避短」

 

最後分享了三個工作中常見的場景應該如何進行「向上管理」。

 

希望對你有所啟發。

 

 

不管怎樣,希望每個人至少都能找到你的「生態位」。當然,能夠“被向上管理”就更好了。

推薦閱讀:

 

 

 

作者:

出處:

 


 

如果你喜歡這篇文章,可以點一下左下角的「 大拇指 」。

這樣可以給我一點反饋。: )

謝謝你的舉手之勞。

 

▶關於作者:張帆(Zachary, 個人微訊號:Zachary-ZF)。堅持用心打磨每一篇高質量原創。歡迎 掃描下方的二維碼~。

如果你是初級程式設計師,想提升但不知道如何下手。又或者做程式設計師多年,陷入了一些瓶頸想拓寬一下視野。歡迎關注我的公眾號「 跨界架構師」,回覆「 技術」,送你一份我長期收集和整理的思維導圖。

如果你是運營,面對不斷變化的市場束手無策。又或者想了解主流的運營策略,以豐富自己的“倉庫”。歡迎關注我的公眾號「 跨界架構師」,回覆「 運營」,送你一份我長期收集和整理的思維導圖。

定期發表原創內容:架構設計丨分散式系統丨產品丨運營丨一些深度思考。

 


來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/31544142/viewspace-2662448/,如需轉載,請註明出處,否則將追究法律責任。

相關文章