新手主管的準備 - 1 (軟體主管的31堂課)

沒有時間嗎？可以直接看這個清單

沒有人生下來就知道如何作為一個領導者，軟體開發的主管也不例外，即便是資深厲害的主管也都會遇到第一次當主管的困難。

無論是什麼原因，當你有機會變成主管時，需要有意識的認知到，主管的責任和義務會跟你過去的工作截然不同。越快有這樣的認知，並且越快做好準備，你就越有機會成為一個好主管。反之，沒有這樣的認知並且也不做準備，就會有很大可能變成傳說中的壞老闆。

工作本質上的改變

以軟體開發的主管為例，在你變成主管的那一天開始，工作就有本質上的不同。無論之前是不是擔任團隊領導(team leader)的角色，作為主管之後，你的責任範圍就會自己擴大為「團隊」，並且近一步擴大到「其他團隊的互動」。

根據團隊的規模大小，在人數很少的團隊，主管也會進行實質工作，例如撰寫程式，測試等等。然而，工作本質上會讓主管必須要更關注「團隊其他成員」如何完成自己的工作。表面上，簡單的方法，是透過code review。實際上，更推薦新手主管至少每週要找一小段時間，直接坐在某些團隊成員的旁邊，和他一起pair programming。這並不只是兩個人一起看著同一個螢幕寫程式，同時也代表可以了解團隊成員是怎麼完成周邊任務，例如撰寫文件，撰寫測試，執行測試，檢查是否符合規格等等。

工作本質上的改變必須要真正被「實踐」。實踐的方式就是必須要認知時間的重新分配。

工作時間的分配

大部分的人會傾向做自己「喜歡」做的事情。很遺憾的是，如果新手主管只做自己喜歡的事情，那有很大的機會會造成團隊的失敗。

一般來說，新手主管至少每個月都要和團隊成員進行一次1vs1的懇談。至少每週要花1小時，重新檢查一次目前重要事項的進度，以及風險評估。至少每週要花一小時，和重要相關的其他團隊主管溝通。至少每週花一小時，和自己的主管溝通......這些零零總總之的「至少項目」，如果沒辦法有效進行，那麼會花上起碼1/3的工作時間，而且可能也達不到該有的較果。這也是為什麼許多新手主管看似忙得要死，但卻常有溝通問題。

時間，是軟體開發裡面，最需要被控制的資源，但也是最不容易被控制的。主管會比工程師更需要知道怎樣有效分配時間。

衡量成果的改變

作為新手主管，必須要認知到衡量自我成功的要素，會是團隊的成功。換言之，任何團隊的問題，無論是不是自己造成的，都會是自己的問題。誠所謂權力越大，責任也越大。

認知到衡量成果的改變，也代表你需要追蹤和關注的，不只是個人的產出，還會是團隊整體的產出。並且，規模團隊越大，個人產出會變得越不重要。舉個極端的例子：假設一個大型軟體產品開發團隊裡面，有前端工程師，後端工程師，手機app工程師，維運工程師等等，每個工程師小組表面上都按照標準完成任務，但是整合起來就是會有各種問題，那麼這仍然是個失敗的狀態，而軟體主管是這個失敗狀態的主要負責的人。

要做好資訊相關的主管任務，其實相當不容易，當至少有認知到以上的改變時，就可以開始進行準備工作(參見 新手主管的準備 - 2)。

絕不犧牲品質 (軟體主管的31堂課)

無論是大型軟體公司，還是小新創公司，軟體主管常會面臨到時程壓力。畢竟快速交付產品並且到市場驗證，遠比花個數年慢慢搞出一個可能沒有市場的產品來的有用。速度絕對是成功的關鍵因素。再者，孫子兵法有云：兵聞拙速，未睹巧之久也。似乎都在說速度比任何事重要。

然而，做完軟體主管，唯一不能做的事情，就是犧牲品質，現在犧牲品質，下一個犧牲的就是自己和開發團隊，接下來就是公司本身。

兵聞拙速，未睹巧之久：指的是快速決定一個方向，並不指隨便打一場品質低的仗。品質低劣士兵前往戰場只有死路一條（或者只能期待對方更差）

為什麼不能犧牲品質？

(1)如果PM/Sales/BD說可以不再太在乎品質？我需要在乎品質嗎？

當然要在乎品質，事實上，負責任的人會是決定的人。當軟體出現問題的時候，難道PM會負責改code上patch？最終負責的人就是會真正感受到痛苦，並且付出代價的人。軟體品質有問題，會付出代價的一定是軟體開發團隊。其他人既然不能承擔代價，當然就不能決定品質。

(2) 這次改動範圍大，但是有環境上的時間限制deadline-driven的開發，難道我能說品質不好就不上線嗎？例如耶誕夜12/24要上線，無論如何耶誕節都會來，已經做得差不多了難道就不上線嗎？

品質是可以有範圍定義，畢竟不能可能期待大型系統完全沒有bug。但是，即便是有環境上時間限制，如果品質真得無法達到要求，上線只會讓事情變得更糟糕。最近的例子是7 pay，而我們其實可以輕而易舉地找到很多過去的例子。

那麼，為什麼還是會被「逼」上線？許多時候軟體專案主管會認為「這是上面高層交代」他們應該理解時間這麼短，大家工作這麼拼，每天都加班，品質要是有問題應該「高層能理解」！ 這絕對是錯誤的認真，品質有問題的話，「高層」只會知道你們做得不好，更糟的是，你自己已經知道做得不好，連自己的良心也都過不去，而使用者拿到品質差的軟體，當然只是浪費他的時間，這會是個lose-lose-lose三輸的決定。相反的，直接說品質不好無法上線，高層也是知道你們做得不好，但起碼你不會對不起自己的良心，最起碼不是雙輸決定。

(3) 真的沒有時間怎麼辦？

時間資源，品質，規模範圍：這三個軟體開發的要素最多只能要兩者。不可能三者兼具。要三者兼具的話，會自動犧牲品質。然而，其實品質是可以控制，但絕對不能犧牲，因為一旦犧牲，整個軟體不能做出本來該做的事情，有再多功能，用再快時間上市都沒有意義。
因此，其實最應該考慮的是規模範圍，簡單的說就是盡量減少不必要的功能。這其實完全符合Lean-start-up（精實創業）的精神。

如何指派工作 (軟體主管的31堂課)

作為團隊領導者，自然會遇到任務分配，指派工作任務的情況。軟體開發團隊也不例外，雖然敏捷式開發方式中的Scrum方法論，是希望在每個Sprint中採取「自己認領」工作，但其實極少有團隊可以完全做到這點。

指派工作任務最完美狀況是：團隊成員對主管有100%的信任，同時對組織中短期目標也有深切體會；並且都有完整的技術能力可以達成任務；而且所有人對於專案與時間管理都有經驗；而更重要的是，每個人都士氣高昂，迫不及待地完成任務。很遺憾的是，這種情況幾乎不會存在，好的軟體主管必然認知到的是，自己的任務必然是在於讓團隊成長前進，往好的地方邁進，而非期待自己「已經處於」一個完美的團隊。

如果你是個軟體團隊的主管，常常在夜深人靜時自己抱怨自己的環境與團隊，並且自認為委屈，那麼你就是屬於「期待自己已經處於完美團隊的主管」，這通常不會是讓事情變好的心態。

指派工作的方式看似很多，但重點只有幾個：

(一) 指定清楚的目標

指定清楚目標表面上很簡單，但主管自己其實需要考慮是這件事的真正目標，和指定任務的項目。

舉例來說，如果軟體主管指定任務目標為：「A工程師，請把某個AWS的一組VM，從micro升級到xlarge。」這看似清楚目標，但升級機器，必然不是目標，升級機器要達到的結果才有可能是目標，更有可能的是結果後的結果才是目標。

例如，稍微清楚描述目標：「A工程師，我剛收到通知明天由於行銷活動，我們網站流量應該會暴增，為了讓我們能處理高流量，請把某個AWS的一組VM，從micro升級到xlarge。」

但是，更好的方式其實是，清楚目標先指定，然後再討論出來。例如：「A工程師，我剛收到通知明天由於行銷活動，我們網站流量應該會暴增，為了讓我們能處理高流量，我們在AWS上的各種VM和使用的服務，有需要做哪些改變呢？」

當然，目標本身一定要涵蓋作法/行動。沒有具體行動的目標也沒有意義。

(二) 時間視為最重要衡量方式

時間是衡量所有事情的最重要的方式，在清楚指定或者討論目標作法之後，所有的行動必須以時間為衡量方式。而時間除了長度，還有實際完成時間。

例如：「A工程師，根據我們剛才討論結果，我們需要升級所有120個VM，這需要2小時，並且是在後天早上10:30am之前完成」

(三) 寫下來！

指派工作的另一個重點在於，所有任務指派一定要文字化或者圖形化，即便是很簡單的瑣碎小任務，也應該用一張紙寫下來。現在專案管理工具其實很多，例如JIRA。當然也可以用它來指定所有任務。

如何建立信任關係 (軟體主管的31堂課)

一個好的主管，會讓其團隊成員高度信任，在軟體開發團隊中，如果主管可以有效地和團隊成員建立健康的信任關係，就容易達成三贏效果：對企業有利，對團隊有利，也對個人有利。相反的，如果團隊主管不受信任，那麼組織內部就容易內耗，很容易就形成三輸的情況。普通的團隊則是部分成員信任團隊主管，部分則不太信任，主管意識到這點，其實是很有改善的機會。

何謂信任？

信任並不是說團隊成員要變成主管的莫逆之交，在危急的時候就算赴湯蹈火也都在所不辭。當然可以達到這點很好，但在企業團隊內是不太可能。所謂信任是指，團隊成員對主管決策方式以及最做事方式，有預期感，並能相信這樣的決策和做事方式，即便自己不了解，甚至不完全贊同，也願意有效的合作。

如何建立信任。有些事情對於建立信任的雖然有一點點幫助，但效果有限，例如典型的團康活動。有些事情則是對建立信任有決定的影響：

(一) 傾聽了解個別成員：

信任是「個人」心理狀態，因此，有效地傾聽個別成員在組織的需求，針對個別成員的需求，量身定做互動的方式。

傾聽的重點在於「傾聽」，中途插話，表達太多意見都不是傾聽的要訣。

(二) 共同接受並完成工作上的挑戰：

這和傳統軍隊建構團隊的方式雷同。一小組人一旦一起面對挑戰，並且度過挑戰，就容易互相信任。在經歷生死戰場的退伍軍人戰友，特別容易建立長期的信任關係，就是因為如此。
當然在企業環境大概不會有生死攸關的情況，但仍然有許多挑戰。好主管的要務在於對挑戰的本身必須要是正面看待，

例如：在跨國企業中研發團隊總是對某國家的另一些工程師作法相當不認同，並常在討論中發生意見衝突。團隊常常對主管抱怨狀況。不適任的主管在此最容易做的事，就是一起跟著抱怨，並且將責任歸於其他人，試圖在團隊塑造共同敵人，這樣短期團隊成員或許會開心，但是衝突並不會因此解決。一個好的主管，會將這狀況是為共同挑戰，讓團隊成員明白如果我們可以一起解決這樣的衝突，不但對組織有好處 - 可以讓跨國團隊更有效工作，對自己也有好處 - 在履歷表中就可以多一項很難得的成功經歷。

(三) 建立一致性：無論任何事情的好壞

建立一致性是在不公平的社會環境中，讓團隊成員認為主管會公平處理事情的最有效方式。所謂的一致性，倒不是指不能改變作法，而是指作法本身有可預期的一致性。

例如，在營運團隊中常常有假日需要輪值的情況，最簡單的方式是直接按照姓名或者到職日期，輪流安排成員在假日值班。表面上看起來是最最公平，實際上有可能是公平，但也有可能不公平，因為每個人上班期間的工作內容可能不同。一致性並不是說不應該輪流值班，而是指輪流值班的班表如何取得共識。例如，每次班表都是每3個月前產生，產生之後，會在兩週內先逐一詢問個別的需要，個人的需求被滿足後之後，在隨即email公布並詢問有沒有需要調整，並且在一週後正式啟用此輪班表。幾次之後，團隊成員對主管的做事方法就有一致性，知道主管在困難事項一定會先詢問個人，調整每個人狀況，還會在所有人面前再度公佈一次，然後再做最後調整。

這樣一次一次建立一致性，無論事情的好與壞，也無論主管個性，就容易建構工作上的信任關係。

如何提昇士氣激勵團隊成員 - part2 - 三件一定要做的事 (軟體主管的31堂課)

激勵團隊成員士氣，是在軟體開發團隊中，最好的提高績效與成果的方式。這又是一個所有人都知道，但是很難真正做到的事情。想要作為一個好主管，應該要有某幾種可激勵人的行動。

有幾件用處不大，做了不會有傷害，多少會花點時間，如果有其他人的協助當然可以執行，但是不建議軟體團隊主管花太多時間在這類事務上：

* Team Building：找個空擋帶著團隊成員出遊
* 零食飲料：在辦公室塞滿各類型零食飲料
* 生日卡片，慶生會等等

真正有用的事情，恐怕都要花點時間，有幾件事情的做法可供參考如下：

一：透過聆聽了解團隊成員的需要

在1vs1的時候，放下心中成見，專注於聆聽團隊成員的真正心聲與需要。每個人會工作有必然真正的原因驅使並激勵這個人。

困難點在於每個人的激勵因素都不同，一般認為，軟體工程師會持續激勵有高績效產出「可能是」因為：
(a) 完成程式執行順利時候有種滿足感
(b) 自己也能夠學習成長
(c) 團隊溝通順暢協作愉快
(d) 強烈認同組織目標
(e) 對團隊有影響力 能夠被人認可
(f)  ....其他...(家庭之類)

以上雖然都有是原因，但是每個人真正的「激勵因素」卻差距很大。需要靠one-on-one時，盡量耐心聆聽出每個人真正背後原因

絕大部分的情況下，軟體工程師不會真正為「錢」而工作，當然千萬不要因為這樣就降低薪資，錢是屬於保健因子，沒有足夠在人才市場競爭力的薪資，是絕對無法找到能力好的工程師。但是，工程師會留下來持續高績效的產出大部分也不是因為錢。

二：根據需要，量身訂做能做的事情

聽起來好像是廢話，但是每個人的需要會讓主管該量身定做的事情差異很大。而且執行起來極端困難 -- 不過本來作為主管就是困難的事情。

這點有空會再說明一些實質作法。

三：透過直接了當的方式，表達重視團隊成員

絕大部分的人都是「被需要的」。在許多時候，主管多少會忽略「現在做的很好」的團隊成員，將心思放在做的不是很好的人身上，這其實無可厚非，畢竟，現在做的好的人，雖然通常表示思慮成熟，做事完整，並且也能自我學習。然而，這並不代表這樣的人知道主管「其實很重視他」，尤其是高績效的人常常也是獵人頭無時不刻的挖角對象。

直接了當在one-on-one的時候，對現在績效高的人講這句話：『你對我來說非常重要，我們團隊是真的需要你，我也很需要你的繼續協助』必要的時候可以在one-on-one開頭，中間，結尾都講一次。

如何提昇士氣激勵團隊成員 - part1 - 幾件千萬別做的事 (軟體主管的31堂課)

幾乎所有主管都知道，一個技術能力不錯，且士氣高昂，充滿鬥志希望，正面能量強的團隊成員，幾乎必然帶來高績效的結果。並且，他對團隊的貢獻，鐵定遠遠大於一個技術能力超強，但是士氣低落，充滿抱怨失落，厭世能量強的人。

軟體開發主管最難的地方莫過於激勵團隊成員。因而，能否再困難的情況下激勵團隊成員，就是優秀主管和普通主管的最大差異。

有幾件千萬不能做的事情：

(1) 單純使用薪資福利激勵團隊成員

只要是人都喜歡越來越高的薪資，越來越好的福利。但薪資福利是典型的「保健因素」，利用薪資福利短期或許有些微效果，但長期一定沒用。最糟糕的情況下，高薪資福利會留住成員的身體，但靈魂早就不再貢獻於組織。對團隊其實有更大的傷害，因為如果單純只為了錢留下來，就一定會精算如何在最最少的貢獻下，拿到最最多的利益（參見：公務員官僚體系)

合理或者略高的薪資福利當然是最好的。並且也是不可或缺，然而它只會是保健因素，絕不能當作激勵因素。

(2) 樹立共同敵人

有些主管會試圖建立共同敵人，或許是其他部門的人，有些甚至是同個部門的其他同事。主管透過和低落的團隊成員，一起批判別人一起抱怨，表面上看似同仇敵愾，其實是飲鴆止渴的做法。

這聽起來非常普通，但是，在企業組織卻很常看到主管無意中做出「樹立共同敵人」的事情。主要起因於人類一開始作為群居動物，對抗共同敵人就是群居動物的本能，原始人群居成為小部落，分工合作對抗毒蛇猛獸與惡劣環境，會讓所有人的生存機率大幅提升。現代商業社會發展不過也才不到兩百年，要抗衡超過10萬年的人類演化習慣是需要一定的主管個人知覺和意志力。

(3) 瑣碎的微觀管理

所謂micro management (微觀管理) 是指主管重視各種支微末節，會透過枝微末節的檢核來判斷與採取行動 - 而這個檢核可能和工作本身無關。最最簡單的例子就是組織規定早上9點上班，主管一看到有人9:10才出現，就會主動前往詢問。

根據工作的形態不同，微觀管理其實在某些情況下非常適用，典型的例子是傳統軍隊，或者勞力密集度高的產業。

然而，軟體產業鐵定不能使用微觀管理，軟體開發相關工作，其實有極強的自主性，每個人的產出不可能像生產手機一樣在最末端測試所有該有的東西，這些自主性，會決定整體團隊績效的好壞，主管即便不能提高自主性，也千萬別降低高績效人人自主性。

要注意的事，作為主管其實應該能清楚理解code review並不是一種微觀管理，優秀且高績效的人才通常喜歡「被code review」同時也喜觀「review別人的code」。如果你不能理解這件事情，表示你大概不適合擔任軟體研發的主管。

如何讓一對一面談變得有用！ (軟體主管的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必須要有自己的筆記，千萬不要忽略紀錄

主管的責任：三件不能做的事情 (軟體主管的31堂課)

作為用人主管，是帶領團隊前進的最重要的人。無論團隊是2個人還是200個人，主管應該對團隊的成敗擔負最大的責任。

企業內用人主管(people manager)是指的要直接負責員工的招募，任用，考核，薪資，工作指派，管理，領導，培訓以及資遣。

而現代化企業團隊本身的績效，最大影響因素其實不是某個別員工的能力與態度，團隊主管(領導者)才是最大影響。

無論團隊大或者小，也無論是什麼樣的團隊。團隊主管會大幅影響團隊合作(參考這裡)，也會大幅影響員工對團隊的參與感(參考這裡)，也會大幅影響個別員工的績效(參考這裡)。

簡而言之，團隊主管承擔大部分一半以上的成敗責任，如果是小規模的團隊，也就是團隊加主管成員為五人以下，團隊主管會承擔100%成敗責任。(參見這裡,這裡,這裡)

當然根據組織和工作任務的不同，主管有不同的事情該做。不過，有三件事情是管理上，一個現代企業的好主管，不能也不會做的事情：

(1) 將個人與團隊績效不好，歸為外在因素 
(2) 以情緒感受為先，事實為後
(3) 無法修正自己溝通方式，認為部屬難以溝通

1. 將個人與團隊績效不好，僅歸為外在因素或歸責於部分團隊成員 

當主管個人或者團隊績效不好，無論是業績數字不好，或者專案延誤，或者原定目標沒達成，當然是很多不同的原因導致。

然而，作為主管應該知道績效的大部分來源是「主管與主管的領導管理」，因此，績效不好，當然要先「檢討自己，以及自己管理與領導的方式」。

這並不是說，外在因素沒有影響。當然許許多多因素都會影響成效。然而，如果不是先檢討以及改變自己，作為用人主管，最容易落於「怪罪」

2. 以情緒感受為先，事實為後

某些主管大概參考了許多以「權力」為中心的書籍，例如：這本或者這本。又或許根據個人經驗，知道要說服別人，情感優先是非常重要的。因而在優通重要事情，或處理意外時，常常會以「情緒早於/優於事實」的方式進行。

最明顯的例子就是，團隊某些成員犯了錯，主管可能在第一時間會是說：「我很生氣，因為你做了某某某事情，後來某某結果發生」。

但合理的情況，應該是「某某結果發生了，是因為你做了某某某事情，因而我很生氣」

這並非在字句上的咬文嚼字，也不是探討主管的講話藝術。問題是在於主管本人內心深處事實的重視表達。

前者主管先重視的是「自己個人心情好惡」，其次是「團隊成員怎麼做事」，最後才是「那件事情的結果」。

只要幾次之後，團隊成員在工作進行上就有兩種可能。(a)成員在潛意識中，自然會認定主管是以情緒優先，知道自己無論績效能力好壞，最重要的是討老闆開心，對自己職涯不利，若有機會自然會儘速離開。(b) 成員不知道產出的標準為何，只知道主管的情緒標準。然而，情緒標準在現代化企業中難以作為成效指標，因而難以在結果上確切達到組織要的效果。 

(3) 無法修正自己溝通方式，認為部屬難以溝通

特別是在小團隊(少於五人)，主管與團隊成員的溝通好壞，並非取決於團隊成員，而是取決於主管本人。

主管認為某團隊成員難以溝通有幾種可能，但這些可能性都不是「難溝通」的理由，主管應該都能和任何部屬達到「工作期望的有效溝通」 

(a)：某成員是我招募進來，但怎麼講都很溝通：如果他真的這麼難溝通，表示招募選用對該主管來說是失敗的，換言之，責任仍然在主管身上。

(b)： 某成員不是我招募進來，怎麼講都很難溝通：主管擁有考核和解雇的權利。難以溝通的時候，應該以事實溝通成效，如果主管對自己有權限的屬下都難以溝通，更別說沒有權限的橫向單位。

當主管認為某屬下難溝通，最糟糕的做法恐怕就是在一對一面談時，坦然的溝通說：「我覺得你很難溝通」。因為這表示，主管在內心深處不能理解「溝通是雙向」的簡單事實。因而，很難溝通只能見裡在於「我們兩個很難互相溝通」的事情上。根本不可能建立在「我個人沒問題，是你很難溝通」的事實上。

和前段相同，這並非咬文嚼字，也不是認為用人主管是不會犯錯的聖人。而僅只是要說明，特別是擔任主管的時候，溝通絕非單向問題。必須要先認定問題所在，才能找到正確解答。

當主管認定溝通問題單存於對方，那麼問題鐵定無解，因為問題鎖定方式已經不正確。單只要求對方「改善溝通方式」，最好情況是對方改善了，但是自己沒改善，此問題還是會出現在其他部屬身上。造成主管認為自己的屬下統統難溝通，這種主管應該儘速被開除才是對組織最有貢獻的時候。

當主管認定溝通問題在於雙向，解答方法自然呼之欲出。有幾個方式可供參考：(a) 密集但是以事實為基礎的短溝通 (b) 盡可能使用精確直接而且短的溝通方式 (c) 建立互信關係用以輔佐溝通。 最近沒麼時間所以上述方式會在之後文章再說。

參考資料
(1) 自我感覺良好的認知能力不足