自我感覺良好的能力不足: 預防與解決之道

在軟體開發團隊的招募中，技術能力當然是不可或缺的一環。候選者如何自己評斷技術能力，也許和如何評估候選者的技術能力一樣重要！

換言之，謙虛的人比自我感覺良好的人，可能實質上的能力更好。這在「達克效應」中說明得十分清楚。

達克效應簡單的說：是指能力不足的人通常會高估自己的能力 無法正確判斷自己能力的不足。不過經過提高能力之後，是可以認知到過去能力不足的事實。
這個理論雖然廣為人知，但真正去證實的人很少，因為大家總是覺得很合理，

該論文研究分為四例，無論是哪個例子，結果都類似下圖(註1)

本圖取自論文：Unskilled and Unaware of It: How Difficulties in Recognizing One's Own Incompetence Lead to Inflated Self-Assessments

該圖是取自研究案例二，研究者讓所有受測者考一個邏輯考試，這邏輯考試取自於美國的法律學校入學考(LSAT)，主要看一個人的邏輯思考是否完整，有興趣可以參看這個網站。

當然考試不是重點，考完試之後，將結果分成四組人，最差的就是bottom，最好的是Top。所以在上圖中，很明顯bottom組的結果當然是在最下方。但有趣的是在於，最爛的一組，在預測自己的成績與能力，卻是和實際上差距很大！次佳組(3rd)其實實際成績和自我預測最接近。而成績最好的那組，反而感覺非常「謙虛」！？是唯一反而預測自己考得不好，同時也自覺的不好的一組。但實際上考的成績卻是最好的。

研究有四個案例，考試的範圍跟內容各有不同但結果很一致。

這篇論文，雖然很直觀，但寫得有點幽默，所以竟然還得了搞笑諾貝爾獎，細想其實很有啟發性。尤其在組織中，員工的自我感覺良好是績效評估產生問題的最大因素之一，那麼在組織中有什麼樣的解決方式呢？

預防的方式：招募時的預防

尤其是軟體開發團隊，招募一個謙虛的人，比招募一個很有自信的人更容易找到真正有能力的人。倒不是說有自信是不對的，但自信心往往容易落入低能力的範圍（請參見上圖)。

要判斷自信與能力最簡單的方式有兩種：一者，就是根據過去實際的產出內容來衡量，例如詢問他過去工作中，實際上做了什麼事情，導致於貢獻的產生，而不是只問了貢獻的結果。其二，設定簡單的測試環境，例如直接在白板上討論演算法問題。

解決的方式：衡量產出而非能力

絕大部分的企業組織都知道，衡量員工的績效乃是基於產出，並非能力。當然，能力好的人自然有機會有更高的產出。

在軟體開發團隊中，衡量產出極其困難。每個團隊幾乎都因人而異。有幾個方式倒是可以適用於大部分的狀況 
(1) 員工自評，並且加上3位以上的同僚互評。
(2) code review
(3) quality

由於最近比較忙，關於產出的衡量有機會再寫。:)



------
註一:本圖擷取自該論文本身：https://pdfs.semanticscholar.org/e320/9ca64cbed9a441e55568797cbd3683cf7f8c.pdf

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

建立高度自我激勵之軟體開發團隊的三個方向 (軟體主管的31堂課)

1999年美國的籃球夢幻隊1992 dream team 是所有籌組團隊的人遙不可及的夢想。他們除了籃球技術精湛，經驗豐富之外，更重要的團隊都有拿到奧運金牌的唯一目標，此一目標會讓他們自我激勵，根本不需要額外的刺激。這樣的團隊組成似乎可遇而不可求，在軟體開發的世界幾乎鮮少看到例子。

無論如何，建立能高度自我激勵的團隊，是主管最重要的工作之一。如果你是團隊主管，你必須認識到這是你最重要的任務。

自我激勵會造成工程師的職涯成長，而看得到自己的職涯成長，是能驅動效率的最好的因素(註1)。

軟體開發工作，通常是需要高度的心智活動以及集中的創造力。要造就高強度心智活動，幾乎很難單純由「薪水」或者「物質獎勵」來滿足工程師。加薪獎勵與升遷固然非常重要，但它能維持的效果頂多3-6週，之後所有的工程師都會認為這樣的加薪獎勵與升遷是「理所當然」，並且很快地將獎勵拋諸腦後。這不是說工程師都不懂惜福，而是研發工作本來就很大部分的來源會來自成就的滿足感，而成就的滿足感幾乎是加薪升遷無法長期提供的(參考 1)(註2)。非營利事業有可能天生就存在這樣的激勵因素，例如，慈善組織試圖拯救世界的所有窮困兒童，研究組織試圖大幅延長人類生命到200年...然而這些組織一般都有極為獨特的目標以及具有個人魅力的領導者。

一般的營利組織以及軟體開發團隊如何建立一個能自我激勵的團隊呢？

有三個方向：(1)選對人 (2)找交集 (3)自我導航

(1) 選對人

在選用人才時，就先確定此候選人是正面思考，能自我激勵，自我成長。因為要維護一個人的正確態度，比要矯正一個人錯誤態度來得容易太多。

換言之，選擇已經能夠自我激勵，並且確定此候選人在他過去工作經驗中，已經有自我激勵的事實。

不要選擇個人技術能力很好，但卻在自我激勵上面有非常負面的紀錄。因為，要培養技術能力並不難，但要改變人類的思考模式實在難上加難。現存的coach教練式領導，不過也就只是希望透過引導，造成行為上的調整(參考富比世, 英文版？)，要引導到行為心態的調整，教練(coach)幾乎必須要和學員長期合作才有辦法做到。

選擇的重點在於透過過去的實質發生的紀錄，而不是透過詢問未來的問題。這個做法在選人時非常重要，選擇能高度自我激勵的人才，此人必須在過去工作時，已經展現高度自我激勵的情況。例如，你可以詢問面試者：「請問你最近工作上遇到最艱難的狀況，或者壓力最大的狀況，當時你是怎麼處理的」。這個問題重點在於"最艱難"以及"當時怎麼處理"。有時候面試者可能說沒遇過太艱難的情況，那麼也可以詢問"普通難"或者"壓力普通大"的情況。一個工作超過3年以上的人，當然可能運氣超級好，從來沒遇過艱難狀況，然而絕大部分的人，都可以說出幾個艱難狀態。這時候，不需要太早評斷，也不用加入討論，而是要徹底瞭解，在這個狀態下，面試者通常會表達過去的事情和想法，暫且將其想法放在一邊，妥善記錄事實。最後再由事實來判斷。

舉例以下的對話為例：

主管：「請問你過去遇到工作壓力最大的時候，當時是怎麼處理的？」

面試者：「之前在HXC工作時常常加班到很晚，要趕專案當然覺得壓力很大。怎麼處理喔？就想說當練功啊，學到東西我就要離開了」

主管：「當時你如何判斷已經學到東西然後可以離開了」

面試者：「呃？...就那時候我負責的app都推出去了」

此例的事實是。面試者因環境工作時程長壓力大，處理的方式是轉換心態-當練功，並且設定好離開環境的方式。請記得在此並不判斷好壞，而僅是記錄而已。然而，設定好離開環境的方式並不是以學到東西為主，而是做完東西。光是這樣可能還不足盼對此人是能積極自我學習還是消極無法激勵，需要更多挖掘過去的行為的討論才會確定。

(2) 找交集

我們不可能知道別人腦袋在想什麼，每個人都有所謂 left-hand-column，即便已經選擇最能高度自我激勵，自我成長的人才進入團隊，而且他們也都是非常坦誠並努力工作的人。但我們要知道每個人都有不能說，不想說，或者不適合說的事情。 
有些領導者會試圖找出這些事情，但其實有沒有找到不重要，重要的是「重視left-hand-column的存在」。

一個好的領導者，會找出交集。確保雖然人人有不同想法，但整合個人，團隊以及組織的交集，大家可以獲得三贏狀態(win-win-win)往同一個大目標前進！

當然，一個能力好而且能自我激勵的成員，可以自己找到此交集。不過身為領導者或主管，應該要時時注意：每人對這個交集其實都不太一樣。但好的團隊的每個人，應該都有部分交集。

最底線是：一定要避免三輸的局面。聽起好像很荒謬，但軟體開發的世界偶爾常聽到雙輸或者三輸的狀況。不必要的長期加班，幾乎都會造成雙輸或者三輸。長期加班必然會造成人才的耗損，幾乎也不能避免地造成團隊無法緊密成長，所以起碼就是雙輸，最後也常常造成組織本身無法長期經營，那就變成三輸了。

要建立能自我激勵的團隊，找到每個人不同的交集點。如果真找不到，則很有可能該人才並不適合這個組織，如果一半以上的團隊成員你都找不到目標的交集點，或許你本人並不適合當領導者。

交集點的例子很多，某些有資深能力好的工程師，除了團隊環境之外，或許可兼顧家庭是職涯的重要考量。因此，彈性的工作時間，和受到控制的可在家工作，就會是這類資深工程師(註3)的「left-hand-column」而這可能是最容易取得交集的地方。做法很簡單，就是讓資深工程師自行定義產出和目標，

(3) 自我導航

自我導航(Autopilot)是指團隊成員知道自己為什麼要做，知道該做什麼，知道怎麼做，知道什麼時候做。而更有甚者，他知道自己什麼還不會，所以需要特別努力學什麼。

一個能自我導航的工程師鐵定是資深的工程師，他會自我衡量自己在團隊中的「交集」也會自己「選擇」適合成長的環境。換言之，根本不需要煩惱這樣的成員。

對與已經是自動導航的工程師，僅僅只需要「教練式引導」(coaching) 。領導者或主管，應該必須對coaching有一定程度的了解，如果還不了解，現在就是學習的好時候。

在此最底線是千萬不要micromanagement -  也就是枝微末節都要管。大部分的資訊工作都是高度腦力工作，枝微末節都要管意味兩種可能
(1) 團隊成員根本無力勝任這樣高度腦力工作，而你組出這樣的團隊表示你也不適合作為建構團隊的人
(2) 團隊成員可以勝任高度腦力工作，但你身為管理者想要插手，表示你並不了解高度腦力工作的統御管理方式，所以你大概也不適合作為建構團隊的人。

要怎麼樣知道領導者管理者是不是「微觀管理」？只要看他實際做的事情就知道，當時「實際要做的事情」超出「本身的意義」就是這類型。

舉例來說，上班有規範時間，並非微觀管理，沒有規範在大部分得時候反而浪費大家的時間。然而，毫無彈性的硬性規定人必須出現在辦公室的時間，其實就超過規定上班時間的意義。對軟體開發團隊來說，上班時間規範是為了讓團隊容易一起面對面討論，互相砥礪解決問題。例如組織定義9:30~18:30是工作時間，然而，因個人因素不在範圍之內，例如想要8:30~17:30只要該成員能確保他的scrum團隊夥伴都知道他和大家時間略有不同即可，成熟的團隊的紀律來自「自我認知和團隊合作」，並不需要管理枝微末節。同樣的，「規定現在要加班」也是某種程度的管理枝微末節，順便強調一下加班其實是解決問題最爛的方式，尤其是被規定加班。

抱歉 沒有什麼神奇的快速方式！

組織理論其實並沒有捷徑，也沒有什麼神奇的快速絕招。然而只要方向正確，忍耐個幾個月都會看到成效，但是簡單的路總是難行。當然，特定快速的環境 - 例如非常新的新創產業，還不確定能否獲利 - 似乎不值得這樣長期投資？也有不少人主張時間不等人？然而，對大部分的資訊產業來說，大部分的情況是跑馬拉松而非短跑。

技能與績效的考量:

在這裡省略一件很重要的事情！
我們並沒有討論技術能力和工作績效，但其實在軟體開發團隊中個人技術能力與個人工作績效是非常非常重要的！沒有好的能力與產出，要怎麼激勵自己恐怕都沒太大用處。然而，績效和能力應該比較容易在面試與履歷表中檢核出。因此才不在這裡討論。

---

註1:  要使團隊有高效率，自我激勵是最好的方式 。然而其他方式也存在，例如鞭子與蘿蔔。
註2:  但是如果薪水實在太少，不能滿足基本需求，就不在此討論範圍之內。
註3: 不過要特別注意，資深和年紀沒有絕對關係。必須要是做事態度資深，而非年紀資深。

企業巫醫：應該要在同一間公司待多久？

一個在就業市場工作的人，到底應該在一間公司待多久才算「正常」。就產業的不同，自然有截然不同的答案。就資訊科技領域來說，過於頻繁地更換工作，會讓求職者更難找到好工作。

何謂頻繁更換？當在現有工作遇到瓶頸，自己有機會透過自身能力改善瓶頸，然而卻選擇離開就算頻繁。

真要講個數字的話：
* 工作7年以上，在最後7年的職業生涯中，但不在任何組織中待超過2.5年，就會被列入低優先考量 - 並非完全不考慮，而只是不優先聯絡。
* 工作3-7年，但不在任何組織待超過1.5年，也是屬於低優先考量。
* 工作3年之內，其實到不用太在意。

理由是 考量「大部分的情況」，而非考慮「極端情況」。

大部分的情況是：

工作7年以上，但最後的七年，沒有在任何組織待超過2.5年，表示曾經換過起碼4~5個工作。然而資深的工程師，通常其工作內容是比較困難的，並應該能展現其架構設計與實作的經驗。可是，如果其架構設計，並沒有被「市場驗證」那就很難用各種方式評斷他的真實能力。講得更直白的是：也許這位資訊工程師，雖然有Ｎ年工作經驗，但搞不好每次都挖洞給別人跳，自己拍拍屁股就走了。或者是，也許他工作能力其實普通，但「自我感覺太好」因此老是覺得自己應該找到更好的工作。而更重要的事實是，他的確離開了，這事實也表示這4~5個工作並沒有「留才」的意願。兩年半是最低限度檢驗一個工程師，在技術上能取得「市場驗證」的時間，兩年半表示工程師至少經過兩次以上的績效考核，並且其工作的正面負面評價也容易以事實檢驗。

極端情況是：這位資深工程師運氣太差，雖然各方面能力都好，但就是遇人不淑，常常遇到公司倒閉。或者有不得已的家庭因素。

許多企業巫醫都有各種不同的見解（請參見最下面的參考文章），但整體來說，職涯長短雖然因人而異，但最好不要把自己視為特殊例外。而應該以市場上的事實，來推估自己職涯最適合的況狀。

舉例來說，有些人認為只要沒有成長學習性，就應該換工作，但是過去七年沒有一個工作做超過兩年半，難道表示這五個工作的內容「統統都學精通」？如果老是遇到不好的工作機會，是否就表示「自己對專業工作機會的好壞判斷有問題」而專業機會的判斷，通常也是資深工程師應該要具備。

就業市場的事實是過於頻繁換工作「通常」表示有問題，頻繁換工作的大部分人是屬於通常，而非特殊例外。


參考文章：
* 在一個公司裡為何要待十年的十個好理由
* 在一個公司待太久不好嗎？
* 在同一公司內部發展職涯才聰明
* 在同一間公司不要待超過四年喔
* 你在公司待很久了嗎
* 在一個公司待太久會對職涯不利嗎？

在多個工作機會中的選擇

只要有數年工作經驗，一個還不錯的軟體工程師，在轉職的時候，應該都有可以拿到3個以上的錄取通知。然後，從中選擇一個最好的工作變成另一個快樂的問題。

如何在獲得錄用的公司中選擇？

扣除掉工作距離，家庭因素，法律因素之後(註一)，有以下幾個方向可供在多個工作機會中選擇的參考：

(1) 優缺點列表

將你的選擇寫在紙上，例如Ａ，Ｂ，Ｃ三個公司。並且將你認為的優缺點條列出來。

這雖然是很基本的做法，但將腦中的思緒，用另一個方式呈現，會讓思考者以較高而且抽象的角度思考選擇性問題。

大部分的人，會列出條列項目大概是：使用的技術，工作內容是否有趣，薪資，工作時間，壓力大小，未來發展性等等。

除了薪資與目前使用技術之外，這些項目大部分都「主觀的判斷」。盡可能在優缺點列表使用客觀的資料。

以未來發展性為例，一個成立不到一年的新創公司，無論其產品有多厲害，它的未來基本上有90%的機會會在2年內倒閉，這到目前為止是鐵的事實。而上市上櫃公司，未來發展性應該優先調查過去3年的財報來判斷，而非看目前的股票價格。

再以工作內容是否有趣為例：必須要是「你到職之後會做的工作」來判斷是否有趣，而非是這公司產品很有趣。因為，即使是資深軟體工程師，到一個新地方也有可能會先做最無聊的工作。

最後，壓力其實因人而異，但客觀的判斷也不可避免，應該以「過去一年有多少比例的人離職」這類型的數字做為判斷的依據。

(2) 自身能力所帶來的影響力

除非是你自己就是這公司的老闆，否則，當你加入一個工作時，透過自己能力的產出，對公司造成正面影響力，是唯一你能做得好做的開心的原因。其他皆屬次要。

某些工作的特性，讓軟體工程師本身的影響力比較低，舉例來說，所有傳統的IT工作恐怕都是如此。即便IT工作非常重要，但通常被歸類為「保健因素」：也就是沒有會死，但太好也沒用。

某些工作看似很重要，但由於組織結構龐大，讓資深軟體工程師發揮空間較有限。例如在超大型軟體公司，有上千名員工，即便是非常厲害資深的工程師，其實對組織而言相對重要性也低。一個超過千名工程師的公司，不會有任何一個工程師特別重。

小型公司對大部分的軟體工程師來說，都比較能透過自身能力，發揮較大的影響力。這也是為什麼過去數年，新創公司能蓬勃發展的原因之一。但的確也有可能，大型公司的某些小型部門，工程師反而會發揮巨大影響力，line的故事可作為參考。

(3) 未來的主管

英文俗語： people quit their bosses, not their jobs.  
在有多個工作機會選擇下，未來的主管是誰變成是重大的考量。

(a) 不知道是誰？

特別是超大型企業，新建員工會有「儲備培訓期」因此有可能在加入此公司之後一段時間，都不太能確定未來主管是誰。這在軟體開發的領域機會不大，尤其是對資深工程師來說。

(b) 考量的方式

盡可能以「事實」來考量，而非憑「感覺」。面試時通常會有問問題的機會，此時可以探究事實。基本的事實像是：團隊有多少人，最近三次加班是什麼時候，最近一次績效評估中，產出最好的員工做了哪些事情。感覺則是「這裡看起來好像很溫馨」，「面試我的主管看氣來很溫和」。

大部分的情況下應徵者期待的是「一個好主管」。然而，人非聖賢，要考量的其實是管理風格上最適合的主管。因此，詢問管理上實質作法，就是考量的最大因素。

當然，這些考量的事實，也應該呈現在比較的優缺點表格中。

---

註一：法律因素是指，即便有超高薪水，不合法的工作還是千萬別碰。

何謂：資深工程師

在招募人才過程中，經常被問到「資深工程師的定義是什麼？」

以軟體開發的角度而言，資深工程師有三個面向：

* 技術能力
* 實質經歷
* 團隊合作

聽起來簡單，其實不太容易。

技術能力指的是對「現在使用的技術的直接掌握能力，以及持續成長態度」。

實質經歷指的是「過去曾經做過哪些事，取得哪些成果」。

團隊合作和前述的實質經歷略有關係，不過指的是「處在組織裡，透過自己的能力對組織造成正面的影響」

在人才招募中的過程，在有效時限內，對應徵者針對這三個面向判斷是否符合「資深工程師」是有點難。有幾個方式可供參考。

技術能力

現在使用的技術的直接掌握能力。最簡單的方式是設計考試或者實做作業，根據其結果來判斷技術能力。典型的證照例如SJCP, CCNA都屬於此類。當然， 也常有組織採取直接面談的方式來判斷技術能力。

直接掌握的能力，當然不包含應徵者，自我宣稱說："這個我google的到"，或者，"我不記得但是查得到"。畢竟大家都可以查得到，既然都查得到就不是判斷的標準。

技術能力的判斷上：考試，作業，面試各有其優缺點。簡單的說，人為介入越多，就有不客觀的判斷；但是，無人介入的純客觀單純考試，難以判斷設計概觀等複合的技術能力。

使用半開放性的實做作業，加上2人以上，事先決定好的面試結構，應該是比較妥善的方法。不過，請避免幾個認知偏誤：(1)月暈效應 (2) 羊群效應 (3) 觀察者效應。這些偏誤，在技術面試時會特別嚴重，因為許多人會誤以為技術面試很「客觀」，但實際上，所有面試都很主觀。唯有特別注意偏誤，才能盡量降低主觀性。

月暈效應：因為某些光環，讓面試官覺得應徵者可能很厲害，而沒有去驗證事實。舉例來說，有三十年程式設計經驗，又做過某些驚人專案，就假設此應徵者「隨便學什麼都會」。又或者某應徵者可能是網路傳說的「大神」，就覺得他可能很厲害對團隊很有幫助。

羊群效應：面試之後的討論，如果有人先有意見，沒意見的人可能就會追隨之前的意見。

觀察者效應：因為外表或履歷表的直覺或第一印象，而讓面試官試圖尋找錄用或者不錄用的證據。而非客觀的先收集事實。

最後，在技術上持續成長態度很簡單，能認知到一個事實「當自己學的越多，表示自己不會的越多」，並且真有實質行為-固定閱讀也好，非工作之外寫程式也好，其他任何實質行為佐證對資訊技術有成長喜好。

實質經驗

所謂資深，當然表示在軟體開發類型的工作上，有很多經驗，並且這些經驗取得成果。

資深的實質經驗，通常包含「好事」以及「壞事」。更重要的是，經歷過的壞事，知道如何真正改善它。並且認知到，不是所有錯誤都是別人的錯，必然有自己的錯。

面試實質經驗也一樣要破除上一段的認知偏誤。就不再贅述。

團隊合作

資深工程師，能體會真正的團隊合作要素：(1) 技術溝通透明 (2) 控制進度透明 (3)  立基於事實的溝通

技術溝通透明是指：任何單純技術上的選擇，使用，表現，都是透明的。簡單的說，能真正了解技術完全不需要任何的隱瞞性。

控制進度透明是指：了解透明進度對團隊非常重要，並也了解：控制進度的單位是時間，而不是工作內容。

立基於事實的溝通是指：雖然許多事情必須要有假設和猜測，但就工作上的決定，必須要盡量立基於事實。舉例來說：「我覺得最近的release可能會有問題」這就是一種猜測的說法，然而：「最近的release並沒有執行回歸測試，所以我覺得可能會有問題」這也是一種猜測，但卻是立基於事實的猜測。

Self-complacency v.s. confidence

Recently, I've interviewed a candidate who applied for Sr. software engineer job and he did demonstrate an unusual character of Taiwanese engineer: self-complacency. 

The interview started from a quick technical review to know his skill set base on his resume.

At first, we quickly ask "How do you identify your Linux skills" and he said "I am very good at Linux". Then we ask a few basic Linux commands, for example: "How to know your current disk usage?". "How to know current Linux kernel version". He actually cannot answer much.

Then, we asked "How do you identify your level of SQL?" and again he said "I am very good at SQL". But he actually don't know any basic concept of "outer join" and "normalization". He explained SQL is what he is working on not the scope of his research area. Then we asked "how to avoid SQL injection in application" but he still can't say anything.

Since his resume said that he is "excellent" in English, we asked if we can continue interview in English. He took a deep breathe and then said "no".

Finally, he explained that he can quickly learn "anything" in one month but then forget that in next month. But he still emphasized that "I think I do have the talent of software development, give me a mission and I can commit the code". This might be true that he can learn "anything" quick and "commit code" for the job. But it is definitely also true that no one will hire such risky engineer.

To me, at first, I think it is extremely unusual to see an engineer with 7 years experience has such self-complacency and with such low actual skill set. But then his resume shows that he worked for 6 different companies in past 7 years. Change job doesn't means that the candidate is bad. But it is still a sign for Taiwanese programmer. Another sign is that he did have very good education background and also good delivery in first 2 jobs. But then, he seems stay in there. 

How to distinguish  self-complacency from self-confidence?

We do want engineers have confidence to take challenges. But how can we tell a candidate has confidence or just too complacency? 

During interview, our suggestions are

(1) Check skills by fact

Ask simple, un-ambiguous technical questions. Do not rely on his words on resume. For example, if his resume shows he has 10 years experience in Linux Operation, make sure you will ask at least 3 most simple questions and 5 middle level questions. If his resume says that he has 10 years in Java, make sure ask the last moment of his java coding. Sometime, the answer will surprise you.

(2) Check experience by real actions

Some candidates described experience like this "design XXXX system". This could be very important task but also could be a self-complacency thing in candidate's mind.

If this candidate lead design meeting, come out a design document - even a hand writing document or drawing picture from whiteboard. That means we can check the design and know how many of "special" things inside the design. 

However, if candidate couldn't say any concrete delivery (we don't need to ask him to provide right away, just want to know if there is), then it is very possible that he "believe" that he did the design job but actually the design was inside his mind. 

You need to heck the actual actions and delivery of it. You can ask "please let me know the exactly things you did on design XXXX system and also the delivery at that time"

(3) Find critical point by the actions candidates did

Always looking for fact of candidates did in previous jobs. It is very similar to (2). We will need to understand his behavior via his previous actions when face a critical situation.

However, I am sure everybody will prepare a pretty nice answer of "why you leave your current company". So just save your time, ask other question.

Check candidate's resume and you will always find some critical moment in his career. For example, a project which requires a new skill set, then you can ask how candidate learn new skills. Or, senior engineer might play leaders role in certain situation, then, you can ask what is the worst thing happened during his leading. 

Always Consider Facts

In short, always consider to gather fact during interview and identify if candidate fit your organization through fact, not to guess.

企業巫醫：公司需要你，還是你需要公司？

每年年底照例有不少人考慮轉換跑道

換工作是很個人的考量，每個人狀況有很大的差異。然而，當生涯成長變成首要因素時，其中一個考量點是：「公司需要你，還是你需要公司」？

盈利企業當然需要各式人才，讓企業持續成長獲利。但每個人在組織中的重要性不同，特別是上千人的大企業。即便主事者真心誠意認為「每個員工都是公司寶貴資產」，但就事實來看，上千人的組織，不可能「每個人」都是寶貴資產。

因此，在想要轉換跑道之前，先衡量一下，到底公司需要你的程度如何？請記得衡量標準不是你的個人能力，而是公司需要你的程度。

了解自己被需要的程度有幾個方向：

(1) 有機因素 vs 有毒因素

有些時候，某些人以為掌握特定資訊，是被需要的因素。然而，這是屬於有毒因素。換言之，如果只靠掌握某些資訊是很危險的(註1)

舉例來說：在大企業中，專案從開始到結束有一定的流程和系統需要專案經理維護資料的正確性，例如填寫各種表格之類。然而如果專案經理「很會」填表搜集資訊，並且甚至知道很多「秘訣」，這並不是真正「被需要的」理由，而僅只是資訊掌握。將這個因素，作為被需要的原因，就是屬於有毒因素。又或者，僅只是在一個組織中待了很久，知道許多「眉角」，這並非壞事，但僅靠這點不應該被依賴的原因。

大部分的人，都能靠自己的能力產出價值，這就是有機因素。最簡單的情況就是：一個程式設計師撰寫所需要的程式，自然就產出價值。又或者一個廚師的手藝驚人，自然可以產出有價值的菜色。

有機因素和有毒因素都可以被培養，但是，培養有機因素的道路比較長遠。

(2) 換！

有些工作，天生取代性高。例如：餐飲業的員工，只要有心學習，絕大部分的人都能成為一個好的餐飲業員工。

有些工作，很具有專業性，只是在某個特定組織內，取代性很高。例如：在大型軟體組織(例如微軟)的工程師，在數萬個工程師中，其實任一工程師並沒有絕對的必要性。

屬於這類型的狀態下，要提昇被需要的程度，最快的方式其實就是「換」。

但是在「換」之前，需要確保兩件事情：

(a) 現在的工作產出已經超乎別人的預期：也就是說，別人(同事,老闆)很確定你做的非常好了 

(b) 提昇自己的個人能力：說來簡單做起來難，尤其是在大組織中。但就現有的工作範圍往外擴張是最好的方式。

(3) 避免帕金森法則

帕金森法則：請先參考wiki的說明。

當在大企業做了3-5年之後，很有可能落入帕金森法則陷阱之中。也就是會盡量「擴大本來不需要的時間與資源用來完成工作」。這在過去的研究中有相當多的證實，並且全世界所有政府機關都有此現象。

一旦不自覺的落入帕金森法則，會下意識的降低自己的效率，產出和學習新技術的能力。自己的低效率，會成為成長的障礙。在員工能自我解決此問題之前，對大組織來說，都是「員工需要這個公司」而非「這個公司需要員工」。同樣的，對於小組織而言，公司需要員工的而非員工需要公司的機率會大得多。

---

註1：但是業務掌握客戶關係則不屬於此類，客戶關係並不是資訊，而是透過長期互動累積而來。是屬於資產的一種。
參考資料

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

How to build a self-motivated software developer team

A team which all team members are self-motivated is a dream team where everybody want to join in. But, it is really rare. Well, maybe the 1992 dream team was one of the cases but we didn't see many examples in software developer's world.

Nevertheless, to build a self-motivated team is a major task of a manager. If you are the manager, this should be your priority-zero task, and should be only one zero, if you are going to build a new team.

Self-motivated might be the best way to drive software engineer's performance. Since high productive engineer works high involved in creativities and mental work.  These are hardly be gain or impacted by salary or physical award (reference: 1, 2, 3). Sometimes it could be driven by a noble target: save all poor children in the world, increase average human life to 200 years. But unfortunately, that kind of things normally happens in non-profit organization with a born charismatic leader. 

So how to build a self-motivated software developer team in a common working place?

Three key points: (1) selection (2) intersection (3) automation.

(1) Selection

If a member who is already a self-motivated person, then it will be easy to keep his good attitude. Since it is pretty hard to change a person's mindset, therefore to get a right person is the most easy way.

Do select a person who already has record on self-motivation. DON'T select a person who has good skill-set but has bad records on self-motivation and you believe you can change his/her mindset, I won't say it is possible but you need to understand that you really have much less changes. Since you can't be with the person 7x24 and his mindset is only inside his brain.

The key point of selection is try to understand his past. Do not judge his "self-motivation" by ask future question like: will you be self-motivated in our team? Understand his past working experience by asking the difficult moment. Especially, sometime he might not be in spotlight and what he did on that moment.

Again, identify a person's past is the best way to select right attitude candidates. And a best fitting person can really have positive impact for the team. 

(2) Intersection

There is no way to read team member's mind. People have left-hand-column, even if you already selected best people to join your team and you were very sure they all are honest. But they surly have things which can't tell or won't tell.

Some leaders or managers will try to dig it out, it is fine to do but not that easy. The best way is to admit the existence. And then leaders should focus on the intersection which is the area that covers the target of a single team member, the team and the organization. And that is also the area where creates win-win-win.

A self-motived member could find that area by himself. But if you are leader/manager, you should keep in mind that figure out the area and knowing the area is very different in each individual. To fine tune a bit earlier can largely reduce the risk of un-motivated situation.

For example, "Ken" is always in good performance and deliver pretty good result. And you believe that you knew that his career interesting is pure technical area. Which means he might want to be an architect in the future. However, if you see he is pretty happy to lead junior members to work out teamwork activities, for example : organize a study group, handle company travel, or year end party. That might be a sign of that he is actually want to be a manager in the future. If his actions is toward his goal then it is fine. However, if his actions didn't reflect your assumption, then it is your time to reset yourself or/and make a little changes.

The bottom line is to avoid lose-lose-lose situation. This sounds funny and should not even considered to happen. But there are too many true sad stories existed in the world. An usual/typical sample in software developer's world was: a team (which members are well-pay) worked over-time on an ambiguous project for months, delivered a product which didn't fit PM's expectation, company lose money, members lose life, customer didn't get result: no body wins.

To avoid 3-lose situation, make sure there is an intersection of all. If you were the manager, make sure you can guide your members into his own intersection. But if you really see that there is NO intersection at all, make sure to create one.

(3) Autopilot

Autopilot means a member knows exactly what to do, how to do. And most important thing is if there are tasks out of his current skill set, he will know how to learn. He can even do self-consideration of intersection and selection. Totally worry-free.

Again, if the selection was done good, to let team member become autopilot will be easy. All you need to do is coaching. Coaching is another topic of a few books plus lots of trainings/experience. If you are an experienced leader/manager then you already know how to do, just reminder to keep open your mind. And also please keep in your mind that open-your-mind is never easy.

The bottom line is to avoid micro-management.  Software development is highly brain consuming job. Micro-management never works in software development, it does work in other kind of job but it definitely doesn't work in software development. If you need to talk to your member about when to arrive in office, when to leave, what to update in Slack, how to write email. That means you are NOT trying to build self-motivated team or this specific person won't fit in a self-motivated team.

Sorry, No short-cut

There is no short-cut in for organization theory. However, practically do the right things normally will get the positive result in a few months. Of course, sometimes in a rapid startup environment, it seems no time to wait. But most of us in software developer world are running marathon not a sprint.

Skill sets and performance concerns:

There is one more thing. I didn't discuss skill sets and performance here. But this is actually extremely critical for a software developer's team. Without an excellent skill sets and performance delivery the self-motivated will be useless. However, this "should" be not difficult to identify during interview and resume check.

中高階人才選用：成長心態鑒別的技巧

或許Carol Dweck這名字有點陌生，但是這位1946年出生的教授與她指導的學生(Lisa S. Blackwell, Kali H. Trzesniewski 這兩位才是研究作者，教授是列為共同作者) ，闡述的學習成長理論，卻經常的出現在教育界與職場上。

簡單的說，根據對美國小朋友的實驗，鼓勵「成長作為」比鼓勵「天賦能力」更能讓小朋友學習快，解決問題更有彈性，獲得更好學習效果。說的更直白一點，要多對小朋友說：「你做的很努力唷，好棒棒」「你做的方式很有創意耶，好棒棒」，千萬不要對小朋友說：「你好聰明唷，好棒棒」「你好厲害喔，好棒棒」。研究者把小朋友的內心，分成兩種心態(mindset)：成長心態growth mindet，以及，固定心態fixed mindset。說的更直白一點，這些研究認為擁有成長心態的小朋友，未來的發展無限，人生就是彩色的。由於這個研究，引發了之後的更多類似相關研究，對於教育者而言，某些過去鼓勵方式，反而可能對小孩子有錯，而後，這些研究者，成立了 Mindset Works公司，開始賣服務與各類教材。

各企業巫醫們，自然能從中獲得啟發。比較好的像是lifehack，所做的此圖也還真的有啟發性。

對於企業組織要選用中高階人才，自然會希望找到「具有成長心態」的而且「很有能力」的人。換言之，就是要找在龜兔賽跑中，早就已經跑很快，而且也謙虛向學的兔子！對於已經具有十多年工作經驗的老江湖，確蠻有可能在面試過程中，不著痕跡的隱藏自己。那麼企業要如何找到具有「成長心態」的人才，而非找到「很會面試隱惡揚善」的人才？

當然企業不可能重複一次Dr Dweck的實驗，不過確可以用情境實例面試精神，找到簡單的三個「事實」來鑒別人才。

請緊記情境實例面試的原則：了解此人過去的經驗與能力，而非此人「對未來的憧憬與幻想」。換言之，企業組織雖然是為了未來，才需要雇用人才。但是，鑒別人才確必須要依賴了解這位候選人「過去的事實」。

1. 困難問題實例：最近2,3年來，解決最艱困的工作方面問題是什麼，自己如何解決？

這個問題必須要問的簡單清晰。畢竟一個有10多年工作經驗者，必然會遇到困難問題，而既然是最艱難的問題，必然有下列幾種狀態，確實問出幾種客觀狀態，來鑒別此候選者的成長心態。

(a) 問題的艱難程度：不能太過簡單無聊的問題
(b) 此人對此問題的獨立貢獻程度：也就是是這個人「做」的，而不是他「叫別人做」。
(c) 問題解決方式的創意：這和下一題可能有關，但艱難的問題不見得要用創意的方式解決。

如果是資訊科技產業，這個問題要修改為「技術相關的艱困問題」。

2. 創意問題實例：最近5年內，對組織做出最有創意的貢獻是什麼？

此問題的基本精神在於，一個具有成長心態的人才，一定是會做出有創意的貢獻。當然也不可能每天都有創意，把時間放長為五年，應該已經很寬鬆。必然要透過這個問題，以及接下來的對話，確實問出以下客觀狀態：

(a) 這個創意，是此候選人「做」的，而不是他「叫」屬下做，或者是「建議」別人做的。
(b) 這個創意，範圍夠大，確實有所貢獻。
(c) 這個創意貢獻是否能有實質證明。

3. 失敗問題實例： 在工作上，做過最爛最失敗的事情是什麼。

雖然這是面試的老問題，但此問題必須按照事實，看出是否有「避重就輕」。特別是，許多工作十幾年的人，在職場都可以歷練出舌燦蓮花的本領。因此要檢查幾個事實狀態：

(a) 問題的嚴重性：確實有些人運氣特別好，工作十幾年都沒犯錯過。但這個機率實在太低，當一個候選人簡單的講一些根本不是失敗的例子，大概就只是避重就輕。面試時，可以簡單值說：說這些失敗其實根本不重要，能否在舉一個「嚴重犯錯失敗」的例子。另外也有可能是，其過去十幾年來工作內容太不重要，以至於沒有嚴重失敗的經驗。

(b) 失敗的歸咎責任：詢問問題時，一開始請讓候選人自行暢所欲言，許多固定心態(fixed mindset)的人，在能夠暢所欲言的時候，自然而然的會把責任轉移到非自我本身。例如：「那時候我們的QA根本沒找到問題，所以後來系統出錯的時候...」或者是「當時我們的人力不夠，所以就只能拖延...」

(c) 事後的影響：成長心態的人，對於重大失敗會有決定性的影響，因此，這個失敗事件，能否對他後來的「行為」「想法」有改變才是重點。

固定心態的人，很有可能會說「以後運氣還不錯 就沒發生同樣的事情了」或者「也就是因為如此 所以我才想離職」，更慘的是，規避了解失敗的真正原因，特別是曾經當過主管的失敗例子：「因為之前的屬下太過自由導致出問題，所以我現在就很嚴格管理所有細節」「那時候跑scrum有很多問題，所以現在都不用scrum了」。

成長心態的人，則比較傾向找到失敗的真正因素，改善真正因素：「那時候跑scrum有某某問題，所以我們現在scrum會做XX調整」。而重大失敗，更是會變成具有成長心態的人，隱含的內心記錄的一部分。