天天看點

你有沒有亂用“leader”,擔當是個好東西

PS:此文為個人認知,不足處請多多批評。

近期在一線leader(經理)身上發現了幾個case,然後又回想起前幾年自己做的一些傻事,可能都屬于明面上leader不會說什麼,但私下會有情緒的類型:

Case 1:下遊背鍋——聲量小的成本。

有一次作為技術負責人跟一個産品線leader(某一條産品線負責人,非總産品負責人)去開會,讨論我們是否需要采購一套系統。

首先,系統各種資訊,對面公司都不願意透露太多細節參數,是以很難做判斷,然後對方明确表明不會提供源碼,隻願意開放API對接,而我們自己業務方甚至有些二五仔的一直催着趕緊上系統。

作為老司機,我當然微微一笑,類似這種不明不白的系統采購進來絕對是坑自己的技術兄弟,但是技術層面一般來說沒太多決策權,隻有風險預警和方案選擇建議,于是便push産品leader正面回絕。

誰知這個産品犢子(産品果然是技術永遠的敵人),說了幾句“不合理”、“不合适”、“有沖突”、“我們有這個功能了”,之後便全程被業務方蓋住了聲音,于是産品端口的控制權便旁落給業務方或者産品端口開始事實上的缺位了。

我見勢不妙,急忙說了幾個實施難點,以及準備了一個清單,讓第三方準備,不愉快的結束了會議,不做任何承諾,先擱置。

事後質問産品leader為什麼不硬剛,你知道接進來成本多高的時候,那狗犢子來了一句,我已經說了啊,他們不聽,我有什麼辦法,我懶得跟他們争......

這傻犢子,不知道他的所謂不争會導緻技術團隊好大的坑......

Case 2:事不關己高高挂起。

某條線的業務方(非上述業務方),之前着急忙慌的跑模型,非要去外面采購一套系統自己營運。

一段時間後,找着我們CTO(我的leader)哭鬧,說是外面系統太不穩定,性能也差,資料稍微上量後便各種卡,外包團隊的意思大概是伺服器有問題,他們沒法解決。業務方現在希望部署回來,并且以後由我們維護疊代......

這個業務線并不是我們核心業務領域,屬于可接可不接類型,考慮目前資源情況,和後續的坑點,當然是盡量不接呢。剛好,這個事情又落到了上面那個産品leader手上,這癟犢子可能認為坑主要是技術團隊的,又是CTO傾向接住的業務,便又開始事不關己高高挂起了。

于是,得罪人的事情又落到了區區在下身上,這裡是直接闡述了該項目有哪些風險,以及我們目前的資源瓶頸,最終隻答應幫忙部署到我們自己伺服器,但是維護以及疊代不會參與,由于态度有些強硬,我私下瞟了下CTO臉色貌似不太好......

最後,此事也确實慢慢無疾而終,沒産生什麼影響。

Case 3:無來由的鍋——好人我做,背鍋leader來。

這個Case來源于此文原型:【周複盤】複盤機制如何在新團隊落地?

這裡其實還有一段聊天記錄,大概是這樣的:第一次産品同學做CaseStudy,有點擔心是批鬥會,不太想參加,于是質效leader将這個鍋算是完全的抛給了其leader。

你有沒有亂用“leader”,擔當是個好東西
你有沒有亂用“leader”,擔當是個好東西

很簡短的對話中,其leader(區區在下)被連續當擋箭牌工具人用了兩次,而且類似這種案例在很多場景下發生......

Case 4:跟着躺平——一個團隊不能有兩個思考的人。

我這邊接手了一塊産品業務線,于是與原來該産品線leader說了下分工,大概意思就是我是過來學習的,也能給團隊提供更多的資源(技術資源也是資源啊!),初期我會有一些規劃,團隊内的工作你自己繼續管理,之前的規劃也繼續做,不要等我,于是在愉快(真的愉快)的相處下,進入到本周周會。

周會上,我發現一旦是該團隊有疏漏的地方,這位産品leader,自然而然、驕傲的說道,這塊XX哥會做規劃,這塊XX哥下來會組織,這塊我下來跟XX哥聊聊,聽聽他的意見,這塊XX哥說不需要提供......尼瑪,我馬上又成為背鍋俠了!

PS:這裡要注意,這個産品同學絕對不是因為不滿意我的存在而這樣說的!

總結下來,出現這種情況的主要原因是:

團隊中如果出現一個新leader(可能最強的人)後,那麼其餘人甚至是之前的leader,更傾向于停止思考,事事請示,躺平等待帶飛...

以上Case,如果對應權責利模型,其結果貌似又是很合理的,但都有點奇怪的是,這類同學在晉升,或重大機會來臨時往往不會被作為首選,甚至可能會被認為沒有擔當,責任心、有擔當對于往後的路,都是重要的特質,因為會遇到更多可做可不做的三不管情況,如果再進一步的時候,這種鍋該怎麼甩呢?

你有沒有亂用“leader”,擔當是個好東西

PS:這裡是說通用情況,不是針對上述同學!!!

其實上述同學能做到leader還是很聰明的,一定是其“本質”工作做的沒什麼問題了,專業知識不會有太大問題,但是有些“聰明”在很多模糊地帶,三不管地帶,甚至明确非自身領域的偏沖突地帶就會被着色,什麼“老好人”、“不得罪人”、“和稀泥”之類的法寶慢慢就出來了。

“事情到我為止”、“事事有回應,件件有回響”也未必是完全正确的事情,我們要不要做一件事情,有一個标準;我們要把一件事情做到什麼程度,也要有自己的判斷。

有些事情,多做一點深陷泥潭;少做一點又滿盤皆輸,這個度便是各位leader要修行、要掌握的要點,這可能就是所謂管理的火候吧,需要知行合一,多加修煉!

下面提供一個日常案例結束此文,僅僅是抛磚引玉。

一個多方影響的Case

最近出了一個case:

在我們的業務中有【自營店】以及【合作店】兩種使用者觸點,自營店各方面成本最優、體驗最好,但不能保證總是有足夠的存貨,是以有時候依舊需要從合作店拿一些貨,這裡涉及到拆單,會産生額外的物流成本,使用者多次收獲體驗也不是太好。

對應銷售部門本身有成本壓力,不希望有這種成本浪費,于是回報到産研這邊來了,處理的産品同學大概是這樣回答的(PS:這裡不友善透露業務詳情,隻列概要):

1)描述情況;(這點沒問題)

2)描述銷售部門期望情況;(作為簡報,這點也沒問題)

3)産出結果;(這裡問題就來了)

你有沒有亂用“leader”,擔當是個好東西

這個同學(我那條産品線的...)直接求助到産品負責人了,也沒提什麼具體的方案,就把作業全部交給leader了,我這裡當然是先噴啊(不能等别人罵):

你有沒有亂用“leader”,擔當是個好東西

于是,下來找到該同學落實了下處理節奏:

1)較長的描述該問題出現的原因;

2)提供自營店、合作店近2個月的資料情況,合作店銷量的占比;

3)綜合【成本】【毛利】【使用者體驗】【收入規模】等因素做出一個基礎的決策模型;

4)給出臨時短期方案建議;

5)給出長期方案規劃;

6)與供應鍊側達成共識,與銷售端口達成基本一緻;

7)發出郵件,開始實施......;

這裡有幾個點要注意:

1)具體到産品線的某個領域,你的leader比你更專業的機率很低,你要提供相關的建議,以及支撐建議的相關論據,能資料化、多元度資料化最佳;

繼續閱讀