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.

企業巫醫 - 得罪老闆怎麼辦 (人際關係的過度重視)

得罪老闆（直屬主管）怎麼辦？

眾多企業巫醫都有不同的說法：

某一類型的企業巫醫以案例和經驗強調「如何不得罪老闆」，試圖就源頭解決問題。然而，大部分的作法，都是為了造就謹言慎行的員工。例如「得罪老闆的六宗罪」「別惹十種人」「與主管相處之道」「職場人緣學七招」。這些說的都沒錯，然而 - 除非是在超大型組織或者公家機關 - 職業生涯的發展，大部分還是取決於能力與實質貢獻，有效溝通與人際關係是其中重要的一環，而非全部。

有很多企業巫醫都會引用這段不實謠言「卡內基美隆大學曾針對畢業的 200 位傑出校友進行一份問卷調查，結果發現，成功的重要因素裡，其中85%來自一個人的態度包括自信、熱忱、領導、溝通以及人際關係的能力，另外的15%才是專業知識。」作為開場白，似乎再再強調人際關係的重要。更隱含著，只要有好的人際關係，就解決了85%的問題。

隨意引用未經實證的事情，是企業巫醫的共同特徵。就如同在部落驅邪一樣，告訴群眾，根據某某以前的巫醫說法，現在就是獻祭品用樹枝鞭打驅邪治病的好時機。

大概也是這個問題太典型，可是真實研究內容又和各企業巫醫所引用的有所出入。因而，卡內基大學的官方Q&A只列出問題，但是並沒有直接說明答案，只說這是1918年某期刊登載之研究，但是太久之前了，請自己去圖書館找（參考這裡）。

在此特別感謝google的paper search 學術搜尋，很快的根據年份跟名稱，找到該研究發表的地方(參考這裡，請直接看106至108頁) 

實際情況是：

(1) 該研究並非針對200個傑出校友，甚至根本也不是針對特定學校的校友。研究對象為美國工程師，實際樣本超過7000人。

(2) 該研究，是以問卷形式，將因素是工程師升遷的重要條件分成六組(Character, Judgment, Efficiency, Understanding of Men, Knowledge, Technique)。結果，認為Character人格特質那組條件，是升遷第一重要依據的人數，是其他組的七倍。 眾多企業巫醫所引用85%，應該引用此依據，再經過時間以訛傳訛的結果。

(3) 該研究開宗明義的指出在1900前後，美國的工程師教育問題，認為過於著重技術教育，而在工程教育體系缺乏對人格特質的強化。然而！該研究的人格特質定義乃是指

「common sense, integrity, resourcefulness, initiative, tact, thoroughness, accuracy, efficiency, and understanding of men 」(註1)

光看字眼，也能夠體會到1918年 - 畢竟已經快100年前 - 和今日一般企業巫醫所指的「人際關係」有很大差異。例如：完整，正確，有效率，在現代社會通常是技術的一環，而較少列入人格特質的一環。

過度強調「職場成功85%要靠人際關係」就會讓「得罪老闆該怎麼辦」變成落在自己身上最痛苦的事情。因為，得罪老闆之後就會有「已經失敗了85%」的不實感受。

那麼，已經得罪老闆之後該怎麼辦？和處理問題的基本「事實三步驟」一樣：

(1) 確立事實

(a) 你的市場價值有多少？

必須要取得客觀的事實，而非自己心裡的感想。每個人都認為自己對組織可以產生很多價值，但事實上可能不然。最簡單的方式就是「試著去面試找工作」。在此m，並非鼓勵以換工作解決問題，而是以「測試自己的市場價值」來決定個人價值。如果在3-4個月內，無法找到比現在工作整體薪資高出10%的工作，那麼其實你現在在組織內部的價值是被高估。


其實不管有沒有得罪老闆，只要你受僱者，不是自己開公司當老闆，就應該要確定自己的市場價值。這是最重要最重要最重要，需要知道的事實。也是最大唯一根據。

(b) 得罪的原因是做了錯事，還是只是個性不合接連產生誤解，還是遇到一個糟糕的老闆？

也很有可能你永遠無法知道原因，不過如果有機會知道會比較好。

(c) 職業生涯的目標

(d) 對老闆的依賴程度

(e)...還有很多其他事實

(2) 建立選項

得罪老闆既然為既定事實，就要考慮「應該怎麼做」的選項。在完全被動情況下，人會有無限的壓力，選擇的權力讓有掌控感(不過太多選項也是壓力，參考 註2)。

無論如何，至少給自己產生3個應變選項，以下是一些選項參考。了解或者建立選項，並非一定要做，而是要給自己「清楚可見」的選擇機會。

(a) 不動作

每人都有機會得罪老闆，你不見得是唯一，也不見得是最重要的。不動作指的是不把它當一回事，繼續做好你該做的工作，繼續學習成長。

(b) 大幅提昇績效

如果你的工作績效清楚可見：要注意的是，清楚可見是指「其他人清楚可見」而非自己認為。那麼得罪老闆也並不是很重要的事情，因為你對組織的貢獻的本身，並不會得罪任何人。大幅提昇績效是可行的選項，不過前提是你「做得到才行」。既然你已經看到這篇文章，大概就隱含著這個選項短時間做不到。

(c) 組織內換部門

很多時候，你只是和老闆個性不合八字不合，在大組織內換個部門並非壞事。

(d) 換工作

換工作和內部轉移不太一樣。你必須把換工作當做「自己的選項」而非被動的選項。並且，不要欺騙自己。

有些人是在沒其他選擇的情況下，自己欺騙自己說「其實是我想換做工作」，這容易去找到一個勉強而不見得是自己喜歡的工作。換工作的選項在於，先確定自我價值，知道自己換工作可能犧牲的成本代價，然後視為眾多選項之一。當最後真的執行換工作選項時，在時間上和心態上就有很大的差距。

(e) 建立新技能範圍

自己開公司也屬於這個範圍。換言之，在維持現有工作績效的情況下，額外花時間開創可能性。

以資訊科技來說，主動舉辦workshop，參與opensource專案都可能是建立新技能範圍。然而，那怕是去取得水匠電工丙級執照也都是建立新技能範圍。(不建議直銷保險之類的工作)

(3) 執行選項

即便「不動作」，也是需要認知與執行。執行上有一些要件。

(a) 速度：除了不動作之外，其他的選項在「已經得罪老闆」的情況下，應該是要越快建立越好！

越快能建立選項，表示自己掌握了「時間」。不掌握時間的人，就容易被動的被時間掌握。當你覺得每天忙碌不堪，似乎被事情追著跑的時候，表示你需要先改善自己的時間掌握能力。

(b) 建立回饋方式：任何要執行的事項，必須要有自我檢查的方式確定執行的結果是否和預期一樣。因為執行結果有差異的時候，應該「儘速修正」。

(c) 符合最終目的：當得罪老闆這件事發生的時候，你的目的到底是什麼？

你希望「已經獲得老闆原諒了？」
還是「得罪這個老闆已經沒關係了？」
還是「得罪老闆所產生的後果已經最小化」
還是「....」

執行任何解決方式，必須要符合你本來的目的。這目的當然只有你需要知道，而不需讓那些無法幫你解決任何事情的巫醫當作他的「研究個案」或者「參考範例」使用。



參考文章：換工作的面試-軟體工程師如何展現價值

---

註1 ：節錄原文描述人格特質的「項目」，徵求比較好的翻譯
註2：然而，有許多研究顯示太多選擇也反而造成壓力，請參考這裡。

企業巫醫 - 人才管理...人才根本無法被管理

任何能在企業講幾個小時的顧問，都一定會說「在組織中，人的問題最重要」

雖然這句話說的似乎很有道理，但是等同於廢話。這和「颱風明天會來，所以會刮風下雨」一樣，人盡皆知，說了等於沒說。

但是只要是軟性的課程，例如：成功主管的教練技巧之類。都會開宗明義的，告訴虛心向學的主管們，「人的問題很重要」，並且在接下來的8小時，展示一些似乎有用，但很難執行；或者幾乎沒用，但容易執行的技巧，來讓經理們主管們理解：「人的問題很重要 - 但是也實在太難  - 請自己好好體會，好好努力吧」。比較好的顧問，會拿自己豐富的失敗經驗(註1)，用作為警惕 - 這樣還算有價值。但只靠講話的顧問，就只能如同電視名嘴一樣，以幽默的方式打發大家的時間。

既然知道困難，也應該認知困難的地方，透過承認困難，踏實的因應困難，才能在人才培育與經營上找到對組織有用的創造性作法。

對於眾多企業巫醫來說，讓事情變得越複雜，越困難，越不能解決，自然就容易強化巫醫的效果，並且萬一巫醫的作法不靈驗的時候，也容易找到推卸的方式。畢竟，是惡靈不願意配合你的祈求，不是巫醫的錯。

如果你恰巧是資訊科技的主管：無論是軟體開發團隊經理，或者資訊部門主管，只要你負責「管理」團隊，則團隊的人才經營策略，應該會是你最先要考慮的。

無論組織有多大，無論你的職位有多小，無論人資部門的策略是什麼，無論工作壓力有多大，無論專案團隊所使用技術多神奇......無論任何理由，團隊的人才經營策略，應該是團隊主管首要考量的事情！

每個困難，作為負責管理人才的主管，都應該試圖做出合邏輯的，可執行，有創造力的解決方式：

困難一：區別人力與人才

人才之所以難管理，是因為「人才」根本無法被管理。「人力」才能被有效管理。

所有大型組織，很難真實區分人力跟人才。即便是做機械性動作的生產線員工，在效率和品質上仍然有極大的差別。從早期豐田Toyoto的全面品質管理(TQM)開始，到1999年許多人的智慧統整出精實製造(Lean Manufacturing)：揭示了一件明顯的事實：

「實際做事情的人，才是真正知道怎麼做的人」

但是，這個事實卻也隱含著另一件事情：

「在實際做事情的人之中，有些人才，才是真正知道怎麼做才好的人」


但人力跟人才很難區分。以資訊科技為例，任何可衡量的指標，都只能短暫有限的區分人力和人才的差別：無論是寫程式的速度品質，完成任務的完整度時間，程式維護的難易度，對新技術學習的速度等等。這些可衡量的指標，可以很快挑出老鼠屎，可以有效的找到連人力都不算的冗員，但卻很難在短時間裡認出千里馬。

把所有可找到的指標，綜合起來，確實比較可以找到潛在性的人才。但是所花的時間成本太高，而且利用指標的做法，很可能會無意間讓組織朝向「指標」前進，而非「目的」前進。

例如，以軟體專案為例，如果指標是「完成code行數」，配合「每千行code發現的bug比率」，則有可能會產生一個大而無用的系統，程式碼很長，而且根本不會被用 - 當然也不會有bug。

任何在人才策略上，所使用參考的指標，最好都是「隱性」指標，而且必須是簡單有用，常常可以反覆檢驗。例如，這個員工，過去12個月，曾經「主動」提出並且「實作」過哪些軟體專案重要的模組。或者，這個員工，在過去12個月，曾經「主動」做過哪些和軟體品質相關的事情。


此外，以過去的貢獻和產出為區分的標準：這在軟體產品開發上是一個稍微可行的做法。但是，所謂的過去貢獻，不應該是過去35年的貢獻和產出，頂多是過去3年的貢獻和產出。而也必須要確保，這些產出，能有效被歸屬。

舉例來說，一個軟體團隊有10個工程師，共同完成一個很了不起的產品，然而因為市場的關係，產品銷售不好，最後也停止銷售。這10個工程師，仍然擁有產出的貢獻歸屬。但是！這個軟體專案的專案經理，就應該承擔產品錯誤的責任歸屬。然而，由於大部分的產品經理都能言善道，因此，最常看到的是產品經理拿著過去失敗的經驗，拿來宣稱他「從錯誤中學習」，「得到寶貴的開發經驗」，更糟的是宣稱「產品的方向沒問題是公司策略改變」。

從錯誤中學習當然是寶貴的經驗，但是「必須真有學到，然後在爾後，因這些錯誤經驗而成功」。單只有「失敗的經驗」對未來毫無意義。請參考飛鼠裝跳傘(註2)。


在科技軟體產業，最踏實地的區分出人才的方式是：

(1) 面試時以情境實例面試法，了解他過去「做過的事情」，而不是未來「想要怎麼做事」

(2) 衡量工作情況是以「做出來的結果」，而不是以「講出來的結果」，當然也不是以待在公司時間長短，請假的多寡，發表的意見等等...

(3) 盡量試圖找出人才，而不是找天才。換言之，每個人都有某些能力和特性是組織所需要的，只要這個人可以把能力和特性「貢獻並且產生」出來，那麼他就是人才。反過來說，如果他會10種程式語言，還專精6種作業系統，並且還可以解決NP compete問題的難度。但是，卻因某些因素，沒辦法貢獻他的能力到組織或專案中，那麼他依然「不是人才」

困難二：培育或取得人才

資訊科技產業大部分都會宣稱自己很願意培養人才。少數倒是很誠實地說，他們想要直接用挖角取得人才 - 特別是最近幾年的中資企業。

由於培育人才表面上會遇到「培育後被人挖角」的風險。並且，取得人才，表面上通常能在比較短的時間，開始貢獻到企業。因此，許多在成本上沒有限制太多的企業，對於中階人才使用直接取得，也就是挖角，的機會越來越大。

這兩者都有很大的困難，但就資訊科技的角度而言，無論打算培育，或者直接到人才市場找到最適當的人，都不可能避免要「人才培育」。

資訊科技人才無法由人力資源部門統籌培育，必須要由技術性的部門執行，但是技術性的部門卻不見得有空，也不見得會知道重要性。

因此，常見情況是：「我們是on job training，有問題盡量問」。

代表事實就是：「我們不會，也沒有時間訓練你，將工作交給你之後，你就要自己想辦法學習，並且搞定它，當然有問題資深的人如果有空就會回答你。過一段時間你能生存下來就是好員工」

這表示，這個組織對人才培育的策略是......沒有策略，完全看個人造化和運氣。當然，最後的組織在人才運用的結果也是看造化和運氣。

對於規模夠大的組織，其實是可以用所謂沒有策略的方式，因為人數夠多的情況下，某些人才常常能夠單靠自己的能力，脫穎而出。但是在這種情況下脫穎而出的人才，很容易就會被其他組織「取得」。

雖然人才培育很困難，但是比較腳踏實地的做法是：

(1) 對剛加入的人，無論資深還是資遣，根據組織的現況，給予1-3個月的足夠學習期間，訂立學習計畫，在還沒有正式給予任務之前，有對整個團隊，先有全盤性的了解。

(2) 對於已經在組織很久的人，盡可能就現有的專案，進行延伸學習，這個延伸學習不見得是要去上課，可以提供他們「考證照」的經費，讓他們透過「考證照」來主動學習。請謹記：考證照不見得要考很貴的，因為重點不是在於證照本身，而是在於學習。

困難三：薪資獎勵

對於白領技術人才而言，薪資獎勵難以取得真正效果。

首先，傳統的增強理論，對人才：完全沒用！完全沒用！完全沒用！

但是對人力或冗員倒是有些效果。但企業組織為了表面上的公平，通常會試圖制定一體適用的政策，因此，大部分的傳統企業，或多或少都會運用蘿蔔跟棍子。

薪資獎勵，無論有多驚人，都屬於保健因素。換言之，如果不滿意，就很難留住人才，但如果滿意了，也只是「錢有到位」如此而已，一旦不能滿足激勵因素，換言之就是「心委屈了」，仍然無法用薪資獎勵來留住人才。

但反過來說，用夢想，希望，成就，甚至改變人類的命運等等「自我實現」的理念來作為取代薪資獎勵，恐怕也絕對行不通，因為激勵因素和保健因素，兩者無法互相取代。參考：雙因子理論。

大型組織中的某部門，或者某團隊負責人，通常也無法對薪資有大幅改變的權力，頂多是在年度考核的時候，決定某個人加薪的多寡，或者紅利的多寡。薪資獎勵，對有足夠規模的公司而言，整體結構早就是固定的，第一線主管僅有調整的空間。因此即便可以透過薪資獎勵來激勵員工，也不可能巨幅調整。即便可以巨幅調整，也不可能長期滿足。

因此，資訊科技根本不可能用薪資獎勵的方式激勵人才，留下人才，讓人才持續對組織貢獻。

既然不可能，就要換別的方式：

無法用薪資激勵人才的解決方式：

(1) 選擇

提供選擇，或者讓團隊了解選擇。

早在2008年，Zappos就已經設立了離職獎金。讓想要離開的員工，更容易選擇離開。因為，一個勉強留下工作的人才，肯定不會認真付出，他就會成一個人力，更慘的是會變成冗員。而組織要花更多的時間成本。

在台灣作為第一線主管，大概很難說服人力資源部門執行這麼激進的作法。但是，在職權範圍之內，可以清楚的告訴成員，離開組織是一個選擇，當然很歡迎你做出「貢獻」組織的選擇。大部分的人才，在被鼓勵自由選擇的情況下，一旦做出留下的選擇，其貢獻一定會是「人才」的貢獻。

這也不是什麼新鮮事。

從1945-1962年間，不斷重複進行蠟燭實驗。到最近一本很紅的書：如何讓馬飛起來，之中提到的Amabile所做的獎勵 vs 選擇研究。都不斷指出，有創造性的工作，在事先已經知道有獎勵的情況下，其實績效比較差。

以下摘錄自「如何讓馬飛起來」一書：

60名大學生，他們將參加一項人格測驗才能拿到學分，測驗過程中，研究人員假裝錄影機壞了，無法繼續進行。然後她告訴其中一組，稱為「無選擇─無獎賞」組，他們必須完成拼貼畫來代替測驗。另一組「無選擇─有獎賞」，必須完成拼貼畫，但是可以得到2美元。詢問第三組「有選擇─無獎賞」，是否可以做一幅拼貼畫，但沒有任何獎金。再問第四組「有選擇─有獎賞」，是否願意做一幅拼貼畫，拿2美元獎金。為了加強獎金效果，她在獎賞組創作時，把兩張紙鈔放在他們面前。最後全部的作品由一組專家進行評審。這次實驗裡，獎賞果真激發出最有創意的作品──來自「有選擇─有獎賞」組；但最沒有創意的作品，也與獎賞有關──來自「無選擇─有獎賞」組。沒有獎賞的兩組，得分在兩者之間。就創作而言，選擇改變了獎賞所扮演的角色。創意表現最差的那一組，問題顯而易見：他們感受到的壓力最多。

而「無選擇─有獎賞」，正是大部分上班族工作時的實際處境

但是，如果這個獎勵，是事先有選擇性的，也就是可以選擇，那麼績效會更好。文中所提到上班族工作的情況是，無選擇-有獎賞。

其實第一線主管，是有機會加以改變：只要坦然的羅列選擇，不斷的提醒團隊成員：「這是個全然自由的世界」，「你可以去你想要去的任何地方」，「我絕對不會阻止任何人離職，甚至會幫忙寫推薦信」，當然也要提醒：「我不想要任何人離開，在這個團隊我們會讓每個人有機會成長為人才」，「雖然我不能保證薪水，但我能保證你必有成長」

(2) 人才合作 vs 人力合作 

團隊如何合作，是主管最能影響團隊的事情之一。簡單的說，資訊科技團隊必須要能先考慮彼此優勢，透過發揮彼此長才合作；而不是考慮彼此的劣勢，透過避免發生問題的方式合作。

只要參考經濟學上的比較利益法則，找到團隊成員彼此間比較利益的優劣，就有機會讓大部分的人「變成」人才。

但如果在工作分派是以「剛好誰有空」這種區分方式，就會讓大部分的人變成「人力」。

(3) 成長優先 vs 產出優先

人才的成長培育優先，或者產出也就是績效優先？乍看之下是二選一的問題，其實是必須要獲得雙贏的問題。

請參見：工作太忙沒時間

作為第一線主管，必須要透過培訓以及帶領的方式，有效讓人才成長，透過人才成長，讓產出更有效率。

如果面臨二選一的情況，在短時間當然選最適合的。但是中期長的規劃，必須一定要能滿足兩者。

---

註1: 通常不太會有成功經驗的分享，因為在人才管理有真正成功經驗的人，很難有機會變成企管顧問。

註2: Franz Reichelt， 飛鼠裝的先驅，然而他過去的飛鼠裝實驗都沒成功過，就嘗試從艾菲爾鐵塔跳下，結果當然是...