顯示具有 1on1 標籤的文章。 顯示所有文章
顯示具有 1on1 標籤的文章。 顯示所有文章

8/31/2019

如何處理抱怨 (成為主管的31堂課)


只要是人都會抱怨,然而只要是有經驗的主管,一定也都知道處理抱怨的重要性。過度並且持續擴張的抱怨不但會降低士氣,而且對團隊,對個人都沒有任何好處。

抱怨有分不同的層級,如果僅只是抒發心情,發發牢騷當然無妨。其界限在於,在平常閒聊,抱怨的只會佔不到1/3的時間,而在平常正式討論事情,正式的會議上,抱怨應該只是會佔不到1/20 (5% 或2分鐘)的時間。
主管在閒聊時後聽到的抱怨,大部分應該不用特別處理,畢竟是閒聊。 然而在正式會議上的抱怨則應該妥善紀錄並處理。因為抱怨的本身可能是和工作流程有關,更有可能的是潛在的問題,必須要試圖檢討解決。


案例一:工程師E技術能力向來不錯,然而跟他一起工作的同事,總是會反應他是個悲觀的人。追究原因發現,E無論如何都在抱怨,抱怨目前的現況和組織的做法,抱怨福利薪資等等。過了一段時間之後,團隊成員有些會受到影響,跟著開始抱怨,有些則會忽視他的抱怨。

案例二:在跨國團隊中,另一個國家的工程師會抱怨無法取得某些系統權限,而本國工程師常抱怨另外一個國家的工程師常想要干涉目前自己工作的範圍。



主管處理嚴重的抱怨有幾個方式:

(1) 了解抱怨的事實,根據事實決定行動


如果軟體主管覺得這個抱怨的人其實是為了組織好,而且,大部分的時候抱怨者其實不那麼常抱怨,也不是士氣低落的人,他除了反映工作困難之外,也許也揭露了應該改善的現況。應該進一步了解實情。並且在根據事實來決定行動。

以上面的案例二,雙方雖然都有道理,但主管進一步了解事實後,會發現其實某些系統的權限並沒有分group,這會讓該系統只要有權限的人統統都是最高的管理者權限,所以表面上是合作問題,其實是個技術問題,應該讓系統有不同層級的權限,另一個國家工程師也不是真的想管理這個系統,只是為了工作必須要直接使用,透過另一組人間接使用也很麻煩。而本國工程師也不是真的不想讓其他人使用,只是考慮安全性不應該給很多人管理者權限。


(2) 擁有改變的力量,而不是擁有「叫別人改變」的力量


許多抱怨的工程師常常會忽略「在公司裡面,我是來解決問題,而不是製造問題」

對於主管來說,如果抱怨者其實績效能力都很好,那麼應該化抱怨為力量。舉例來說,當團隊成員抱怨「現在的某系統在部署常出問題,害我需要做額外的工作」。那麼就可以先就事實詢問:「你覺得這對你很重要嗎?這是不是我們應該先解決的問題?」如果是的話,進一步應該跟抱怨者溝通:「既然這樣,你現在在做的是XXX和XXX,這兩件事就先不做,先來把某系統的部署改善,這樣以後你就不用做額外的工作」

讓抱怨者擁有改變的力量 - 就是要調整工作內容和時間。這樣久了,也可以清楚地塑造團隊會往解決問題方向前進,而不會只抱怨問題。

(3) 概念性問題:先記錄並且追蹤


概念性的抱怨是指對公司政策概念的抱怨,例如:為什麼我們公司沒有work-from-home(在家工作)的政策,為什麼上下班要打卡。這類型的抱怨很多時候和「實質工作」沒有很大關係,然而,不處理或者直接用「這個是公司HR政策 我也沒辦法」這種說詞也對大家沒好處。

對於概念性抱怨,應該先行記錄,並且追蹤對團隊成員的影響。舉例來說,對於work-from-home的要求可以先了解團隊成員需要work-from-home的原因:例如需要專心工作,還是需要兼顧家人。如果是需要專心工作,可以提出會在他需要專注的時候。幫忙直接訂一個會議室,或者讓他在距離公司很近的咖啡廳工作,並且記錄一整個月,看看有沒有實質影響。也許,他以後就不想真的work-from-home,也許他會覺得在咖啡廳工作也很好。

重點在於,概念性抱怨其實應該轉為實際可追蹤執行的內容。



主管對於團隊成員的抱怨絕對不能做以下的事情:


(1) 隨意附和,隨意認同抱怨: 表面上這似乎可以拉近團隊與主管的感情,事實上,一起抱怨對大家都沒有任何實質好處。

(2) 忽略重大抱怨:如果這個抱怨是很嚴重的,忽略拖延也沒有好處

(3) 不查證事實根本原因就行動:雖然所有人都知道要查證事實,然而許多事實的根本原因其實不那麼簡單。



8/25/2019

如何讓一對一面談變得有用! (成為主管的31堂課)



做為軟體相關工作的主管,固定和自己的團隊夥伴一對一面談,在外商俗稱 one-on-one:是絕對不能省略的事情!如果無法和自己直屬部屬(direct report)每個月至少一小時的懇談,那麼絕對無法有效的激勵與維持團隊。


案例:C是在大公司的資深工程師,他常常跟我抱怨他的主管不了解情況。而由於該公司是有規定主管需要跟團隊成員固定one-on-one,所以我自然就問「你不是有跟他固定one-on-one嗎?」,C則回答「是啊,但是那也是聊聊天而已,改覺反應什麼也不會改變」


作為主管,要避免上述案例發生,一定要知道如何有效率的進行one-on-one並且讓他變得有用!


如果你的直屬成員超過10人,一對一面談反而更不能忽略或省略。如果你的直屬成員超過15人,那麼你的現行組織必須分層或者分開,除非你的組織是「人力導向」而非「人才導向」否則,超過10人的直接管理已經是極端困難,超過15個人是幾乎不可行。有些主管會驕傲地說,我的直接report-line有35個人,通常這樣的主管已經默默地分出階層,會找尋team leader來取代主管的工作,而大部分的時候team leader才是真正的主管。

一對一面談(one-on-one, 以下簡稱1-on-1)主要的目的有幾個:
1. 了解該成員的士氣情況
2. 了解該成員工作上是否遇到困難
3. 了解是否有需要處理的人際問題
4. 給與成員過去工作表現的精簡摘要:做的很好,或者做得還好,或者做得不好
5. 讓成員給自己回饋


一般來說,1-on-1不應該用來解決「技術問題」,技術問題應該是透明解決,而非兩個人私下解決。除非團隊人數剛好就是兩個人。

1-on-1的推薦作法:


一:固定架構與取得事實優先


當談話有固定架構時,部屬在每一次談話自然就有期待,以及自然地提供所需要的資訊,而這些事實資訊就反映到一對一談話的目的。

所謂固定架構很簡單,就是鎖定2到5個基本問題,這些問題是取得事實,並且應該很快可以回答。舉例來說:

(a) 請問你上次1-on-1到今天為止,有沒有遇到讓你很生氣的事情
(b) 從現在到未來2個月內,你有離職的「打算」嗎
(c) 今天有什麼事情,是你認為我要馬上去做的
(d) 從上次1-on-1到今天為止,你覺得工作開心嗎

這些問題都可以簡要的了解此成員的現況。重點是要用張簡單的紙長期追蹤這些問題。

二:自由討論時間以傾聽為主,下次必定追蹤!


固定問題需要紀錄,自由討論時間更是需要傾聽紀錄和追蹤!

自由討論當然以傾聽為主,在團隊成員還沒徹底講完,只做記錄千萬不要打斷。在結尾時,要說明你記錄了什麼。如果是組織做的事情好壞,公司目前現況,專案進度等等相關的,不用在1-on-1之間有結論,但一定要能夠紀錄,並且承諾會重視他講的所有事情。

重點在此!下一次1-on-1必定要重述他曾經重視的事情。並且,說明這些事情目前的現況,同時也和他討論這些事情對他現在還重要嗎?畢竟很多時候團隊成員只是需要抒發心情,並不真的重視這些,他們可能更重視的是「主管有重視」而已。

三:陷阱!不要做這些事情!


請注意以下陷阱!

1. 千萬不要和團隊成員一起抱怨公司政策,或者一起抱怨某個公司員工或主管
2. 絕對不能承諾無法100%達到的事情
3. 傾聽抱怨是應該的,但導向抱怨成為可執行的行動是最重要的一步
4. 切勿打聽A成員對B成員的個人看法!但可以詢問A成員關於其他員工某個特定時間點做的某件特定事情。
5. 1-on-1必須要有自己的筆記,千萬不要忽略紀錄