MF99 coding 💻

keep learning; keep coding;

工作經驗談:Manager

f:id:mouseface99:20200423223433p:plain

從 2014 年開始接手 Team manager 至今,接觸管理職也有 5~6 年左右了,中間也經歷過撰寫擴編計畫、招募/面試、團隊規劃、績效考核、團隊轉型以及縮編/裁員。

所以這邊也分享一下這幾年下來,擔任主管職的一些心得,也提供給想接觸,或是剛接手管理職的人一些參考。

團隊主管,不管是直接管人、管理多個團隊,甚至於管理整間公司,其實大致上概念是差不多的。

基本上分為兩個維度,四種管理面向

管理 對內 對外
管事 調節工作節奏
工作分配
上層/外部主管的時程管理
成果交付
管人 組織結構
成員成長規劃
接班機制
團隊考核
擴編/縮編管理
預算控制

這邊就照著這幾個面向,來具體聊一聊裡面的細節

管事

f:id:mouseface99:20200428122830j:plain

管事,其實是相對簡單的。 不過這也是大多管理者第一個會遇到的課題。

許多人,或許不用到真正升到管理職。 在擔任資深職務的時候就會或多或少會接觸到管理事情的工作。

可能是管理自己手邊的事情,可能甚至是要帶幾個 Junior 的 member 一起完成一件專案。

這部分的技巧跟內容,其實在當了主管以後基本上也差不多。 不外乎就是

  • 時程管理: 有PM 的話就跟 PM 合作,沒有的話就是自己兼任一點,如何如期的交付成品
  • 資源管理:你手邊有多少時間/人力可以運用。 如何有效率的溝通/分工,在最短時間達到最大產出
  • 外部溝通:如何適時的跟你的主管/PM 回報開發進度,提前反映問題,解決問題。
  • 風險管理:如何預判可能出現的風險,進而提早進行管理(避免或是提前準備)

至於真正的主管,與資深成員的差異。 可能就在於實質的責任歸屬。

畢竟資深成員,直屬主管還是部門主管。 所以能看到的面向,或是能夠承擔的風險相對較高。 因為上面還有一個部門主管能夠協助。

但是如果自己身為部門主管的話,你的主管就是更高層的公司主管,如何把控好團隊內的分工協調,比起時程/資源管理,可能部門主管會花更多的時間在做外部溝通與風險管理(畢竟時程/資源管理可以交付給底下的資深員工,這部分在後面接班人機制會再展開來談)

另外,部門主管同時也擔任了公司高層與基層員工之間的溝通橋樑。

你還記得你在基層員工的時候,對公司的政策/專案時程/資源管理有諸多抱怨嗎? 覺得公司高層很蠢? 決策很怪?

但是當你真正擔任了部門主管後,能接觸到的資訊更多,能知道更多關於公司的經營狀況、部門間的合作情況,甚至是公司的營運方針,策略方向。

這時候也就是真正考驗自己是否能做出正確的判斷與制定團隊的戰略方向/戰術手段。

如何能夠在公司在市場上面臨的殘酷現實面前,又能夠對團隊成員有很好的規劃。 這是初任主管的第一個挑戰!

管人

f:id:mouseface99:20200428122850p:plain

相較於管事,管人的部分就相對複雜許多。

因為事情是死的,人是活的。

活的事情變數就多,偏個人內部的能力、心情、個人喜好、成員之間合作默契,偏外部的家庭因素、感情狀態、外部挖角、對主管/公司的信任與否

這都會讓管理起來有著許多挑戰。 基本上也就是邊做邊學。

找人,用人

這兩個部分合在一起講。 首先,在接手一個團隊之後,你需要先思考

  1. 目前有多少資源? (現有人力 & 目前的 Head count)
  2. 這個團隊在公司的定位是什麼?
  3. 目前的定位與編制,是否足夠? 或是還適合再擴編/縮編
  4. 目前人力結構? 資深/資淺員工的比例是否健康?

有了一些初步的概念後,接著就是要開始規劃,你手上的團隊的未來走向。

目前的定位是否太大/太小? 這個團隊是否能提供更多產出?

在這個方針底下,你的團隊需要怎麼樣的組織架構?

需不需要分小組(by 功能 or 產品)? 小組間的資深/資淺員工的比例如何?

初步規劃好之後,就能夠開始有系統的安排你的 head count 以及撰寫適合的 JD

這樣在招募/面試的時候,你才知道這個 candidate 適合放在哪個位置。

重點就是要把對的人,放在對的位置上。 才能發揮最大效益

至於面試相關的一些經驗與細節,之後可能會用另外的篇幅來展開。

團隊合作

現在的專案的規模,很多時候都不是單打獨鬥能夠應付了(可能有些接案公司例外)。

作為一個團隊,除了每一位成員都能夠正常發揮以外。 互相之間能否合作產生 1+1 > 2 的化學效應,這才是關鍵(有時候處理得不好甚至有 1+1 < 2 的情況.....)

所以首先第一步,需要了解底下每一個成員的狀況,技術能力,個人偏好,成員之間的關係。

合理的安排合作組合 ,工作分配。 以及適時的觀察是否有失衡的情況。

另外我在 工作經驗:PM 也提到的 風險管理 也相當重要!

只不過現在的部門主管的角色為資源分配者。

如何有效的分配底下的人力/時間資源。並且能夠預留 Buffer 來應對隨時可能的風險(新工作/成員離職/成員臨時有狀況要請長假...等)

另外這邊要提到一個重要觀念:

接班機制

團隊成員之間,甚至跟部門主管之間一定要有接班機制。這分成兩個部分:

  1. 成員平行之間的相互代理
  2. 團隊上下之間的分工

平行之間的相互代理比較好理解,大部分的團隊也都有做到(只是可能在程度上的差異),也就是團隊成員之間相互有職務代理的能力。

在某個成員臨時有事情時,馬上能有另外一個成員能夠接手,並以至少 80% 的程度完成原本成員的工作。

另外一個比較常被忽略的就是團隊上下之間的分工,也就是建立分層管理的機制。

管理學一個很重要的概念

4~6人是能夠發揮領導效能的最佳人數

當你的底下成員超過這個數量的時候,就必須要進行分層管理。 但是如何做適當的權利/責任分配,就考驗了身為部門主管的課題。

另外,在分層管理的同時,又要讓團隊成員之間能夠互相補位

我以前的主管帶給我的一個很重要的帶團隊觀念

你要讓團隊沒有你也活得下去,但是有了你以後會更好

有些人剛接觸主管的時候,會急著把事情都懶在手上,深怕底下的人太忙或是覺得底下的人不行。

但是這樣一來底下的資深員工就沒有機會成長,然後主管自己也累得半死。

適時的利用一些責任分權的制度或措施,隨時在團隊中每一個人(包含主管自己),在平行的角度有可以互相 cover 的同事,但是對下又有可以代理你的 Member

慢慢讓團隊變成一個能夠自我運作,不依賴任何單一成員的組織,這樣才能夠長久。 而主管在這多出來的時間,也才能有更多時間可以思考團隊的未來走向或是任何的改革措施。

而不是整天在忙著跟 Senior member 搶工作!

新陳代謝

最後一點

團隊,組織是一個由許多人所組成的。

組織成員會異動,每個成員各自會依照不同速度成長/變化,團隊合作之間會產生不同的化學反應(可能是好的,也有可能是不好的)

所以一個組織在經歷了一段時間後,一定會有所改變

如何利用公司現有的績效考核,或是自訂的一些制度,來做到有效的考核團隊中所有成員的狀況是很重要的。

也就是定期要對團隊做體檢。

針對每個 Member 的工作能力,負責項目以及實質的產出,與 Member 共同討論出適合他的短中期目標,並且定時的有公平公正的機制可以來做考核。

另外,主管對於 Member 的職涯規劃也是需要多花點時間去思考的。

首先在組織上,你希望組織未來往哪個方向發展? 這個方向上需要哪些類型的人才?

如果現在還沒有,是要從外面招聘? 還是可以把現有的人才往這個方向培訓?

再來每個人出來工作,除了拿薪水養家糊口之外,或多或少都對於工作/職場上會有一些憧憬與企圖(可能每個人程度各異,當然也有家裡不缺錢... 出來工作只是交朋友的這種例外...)

所以如何適當的跟 Member 有效溝通,理解他們的企圖與理想在哪(可能是技術成長、可能是薪水成長、可能是職位升遷),如何有效的規劃他們的職涯,而且最好還是跟組織的未來是走在相同的方向上。 這樣你才會有更多適合的資源來幫助團隊成長。

(至於怎麼幫 member 升遷,中間其實有許多眉眉角角的細節與技巧,這邊很難一個個提及... 而且許多時候跟經驗也有關,這邊就先不展開討論)

有成長,就相對的會有汰舊換新的狀況。

如果真的遇到不適合的同仁,或是發展方向,速度跟不上整體團隊的成員,適時的與 Member 之間溝通,找出問題的原因,並且做適當的調整(不一定是解僱,可能是適當的在職培訓,轉換團隊,轉換職務都是可行的方案)

f:id:mouseface99:20200428223357j:plain

木桶效應:團隊就像一個木桶,能乘載多少水並不是取決於最高的那根木頭。 而是最短的那根。

團隊中如果有不適合的人放在了不適當的位置上,除了他自己無法好好發揮之外,很多時候也會連帶的影響其他人的運作,導致整體團隊出問題(不管是在情緒上,還是實質的工作/合作上)

後記

其實我自覺的擔任主管其實並沒有到這麼多年,但是很慶幸的當初我有個好的主管來訓練我如何當一個好主管。 加上在人數 100人上下的公司中,中階主管的其實是可以最容易看清公司全貌的人。

因為對上可以直接對到老闆或是高層管理階層,對下又要直接面對到基層的員工。 所以怎麼能做好兩端之間的橋樑,是一個很棒的實戰訓練環境。

當初也只是想整理一下這幾年擔任主管,或是看了很多主管後的一些經驗,實際寫下來好像要談的面向還真不少。

很多地方也只能點到為止,很難真的細部展開。

一來是篇幅太亂,二來是有些經驗或是需要隨機應變的東西真的很難系統化的寫成文章。

所以就只能針對一些常見的面向,以及我的一些經驗來分享。