來源：王淮
1 堅持你的遠景，但要對細節靈活
作為一個領導者，你需要依賴你自己的遠景（至少在你負責的業務領域內）而那些和你一起或為你工作的人將依賴你的遠見。什麼是遠景？就是對最終狀態的一種描述。是你需要你的團隊著陸的地方。是生效之後的新生活。它是北極星，和方向。這裡有一個例子，當我啟動支付風險團隊的時候，我們只有規則引擎。規則是人寫的。一條規則只是一個擁有非常有限變數的簡單邏輯，例如“如果註冊日期少於30天並且支出大於100美元並且是首次支付並且使用者來自印度尼西亞，則拒絕交易”
人類難以有效的處理10個以上的變數。我們需要更加的可測量化。我們想要使很多機器比人更擅長的事情自動化。從而我們樹立了一個遠景，將我們主要的規則置換為機器學習模型。這一遠景驅使我們增加了一位機器學習領域的博士和另一位在加入facebook以前有類似實操經驗的工程師。賭注巨大，但是未來需要這個。
但你需要對細節靈活，因為條條大路通羅馬。你需要給你的團隊以足夠的餘地空間（wiggle room)，只要你的團隊是朝著正確的方向以合適的速度前進。另一個故事：一度我對決策樹的興趣比迴歸要大。但是實驗演算法的工程師告訴我在選擇演算法的時候他們只有可以忽略的區別。我可以堅持己見（這確實是當時我真實的想法）但我信任他並讓他放手去選合適的演算法。同設計者合作的過程中也有趣事發生，他們對於字型，顏色，行距及其他都有著吹毛求疵的偏好。我通常讓他們由著性子只要對最終結果有益就行。我們想要選擇正確的戰場開戰，這樣的戰場必須關乎全域性，而不是糾纏於區域性戰鬥。
2 只和最好的人合作
牛人只想和牛人一起工作。他們聚在一起就更牛逼。一流的人通常無法容忍二流貨色。什麼決定了“最好的人”？我的理解是那些能夠快速盡其所知，學其所不能，從而完成事情並遠超期望。他們的本能是超越期望，甚至他們自己的期望。對他們來說，足夠好本身從來都不夠好。 只擁有最好的人在團隊中有很多好處。
⑴這讓你更加願意託付。救我的經驗來看，牛人不會信任不熟悉的人。在接受你的幫助之前，他們需要知道你同他們一樣出色甚至比他們自己還強。否則，他們寧願盡其所能的獨立完成。但如果你業已得到證明，他們將會非常信任你並樂於託付給你。一個有著有效託付的牛逼團隊幾乎無所不能。
⑵他們相互為榜樣，並且籍此提升工作表現。這是很好的關注壓力。如果使用得當，可以形成團隊的良性迴圈。
⑶牛人們相互挑戰。我記得一位工程師主管曾就我們能否在規定時限之前完成網站翻譯所需的程式碼修改來打賭，他將把頭髮染成藍色。這樣的挑戰往往是的“枯燥”的工作變成了遊戲。成為遊戲的一部分將非常有趣。當然往往會有更嚴肅的挑戰，而且牛人喜歡挑戰（不管是挑戰別人還是接受挑戰）
⑷牛人們相互學到很多。如果不是因為這裡有這麼多可以學習的話我不會在facebook呆4年。對缺乏經驗的人來說，這顯得越發正確。我們僱傭非常聰明的畢業生，這些人被激發來證明他們的牛逼之處。他們不願來到一個舒適並且沒有挑戰性生活的公司。他們想學很多來豐富他們的經驗，完成不可完成的任務並提升他們的職業路徑。他們想要證明“是的，他們可以”。他們想和牛人一起來實現這些。
你不想要二流貨色但如何遠離他們？首先，慢點招人。在給offer的時候固執一點。我曾無數次的在招聘決策會議上發現那些有著光輝履歷的人無法得到僱傭只是因為某個面試官覺得這人無法給他以深刻印象。在其他例子當中，那些獲得一致通過的候選人仍然無法獲得僱傭機會因為每個人都只是覺得他將將符合要求而已。在僱傭問題上，絕大多數情形下，你要風險規避。（順便提一下我們也會僱用那些沒有全票通過的候選人，只要有一兩票強烈推薦﹣你將樂於在信任你員工的問題上冒險）其次，炒魷魚要快。讓二流貨色存在就像服用慢性毒藥。一天一點，逐漸但終究你會為此掛掉。你要緊你所能的把二流貨色踢到魷魚軌道上（在某些情況下，法律不讓你這麼做）我見過一些慢吞吞的魷魚，那對團隊造成的負面作用可不是鬧著玩的。
3 樹立高期望並且衡量之。
作為領導者，你需要設定高但現實的期望。足夠高使得你的團隊不會感到無聊。現實使得他們不至於油盡燈枯。你要給他們創造一段經驗使得旅程結束回顧時，他們會說：媽的，我都沒想到我居然做了這個。這個屌爆了。在Facebook，象其他矽谷高技術公司一樣，期望同回報相結合，因此樹立明確的期望本身就至關重要。 並且你需要找到一個不容爭辯的途徑來衡量期望。我花了大量時間來和團隊一起描繪我們在下季度裡最重要的3-5個目標。目標被分別委派給單個或一組分工不同的攻城獅，或者被他們搶走。在這一情況下，我們不僅有一個由3到5個衡量指標組成的名單，使得我們可以籍此快速地說出來我們在幹嘛，同時也知道每個具體目標後面是誰。團隊的成功同個體表現息息相關。例如，我當年團隊最大的貢獻是在一年時間裡，通過每季度不同的指標，最終降低了信用卡支付爭議率75%。
有一點要強調的是﹣你還是要現實。在你只有10%的市場份額的時候卻幻想10幾倍的收入增長無疑不現實。史蒂夫喬老爺非常善於推動他的團隊超越潛能但同時也榨乾他們（儘管如此他們是這樣為他們所做的而自豪）99.9%的領導不是喬老爺，當然他們也不需要是。但你仍然可以通過驅動一個可持續性的團隊來取得成功同認識到他們的極限並無矛盾。
在箴言4到10，我將分享我的如下觀點：
⒋ 傾聽資料但不要單純依賴之
決定產品方向時, 要的是想象力, 激情和膽量, 而不是資料. 資料能讓你的團隊沿著正確的方向前進而不出軌, 也有助於產品從“一開始是什麼樣”到“最後應該是什麼樣”的逐漸優化成型. 但資料不能幫你決定方向. 舉個例子, 當我們在人工智慧(機器學習)上壓上我們團隊所有的資源的時候, 我們忐忑不安. 但是我們堅信一點, 現有的基於人工規則引擎的防欺詐系統會很快成為死衚衕, 因為它太死板而且不易規模化以處理大資料。所以, 就像在電影指環王中Frodo明知通向Mordor的道路很黑很冷很危險, 但那是一條他必須要選擇去走的路; 我們選擇了在機器學習上壓上所有的寶。失敗, 整個團隊會很難看; 但我們決定走艱難但我們認為是正確的路. 這種思路同樣應用在如何設計用於使用者報告(外部工具)和案例審查(內部工具)的工具來應對潛在的欺騙行為。 我們最後決定的方向是”進行自動處理”和”建立反饋機制”。直接拋給人工來處理總是很容易被選的一條路, 因為只要建立一個人多人傻的客戶支援團隊即可. Lame! 我們希望通過自動處理來解決大部分的欺詐案例，而把精力則放在那些確實需要單獨處理的特殊案例上, 同時把從業務支援團隊(即客戶支援部門)的處理意見自動採集並整合到下一輪的機器學習中去。由此, 我們的機器判斷會越加精確和聰明且與時俱進.
但你不能忽視資料。沒有資料的支撐而一味靠直覺走黑路, 很容易走岔道, 甚至大錯特錯。有一段時間我們認為爬行工具(通過分析關聯的cookie,信用卡)可能可以找到很多欺詐的同夥。通過實驗結果卻發現, 這種預期是否成立很大程度上取決於當前流行的欺詐行為的特點. 比如, 當失竊或販賣信用卡的案例非常普遍的時候,關聯分析是一種有效的方法。但如主要情況是帳戶被黑或小寶們冒用媽媽的信用卡去網遊消費時，關聯分析就作用不大。直覺在現實前面碰了一臉的灰。 不過幸運的是我們很快意識到這點且把這個專案叫停了, 所以沒有浪費太多的資源。
另外, 順帶提一下A/B測試。A/B測試並不會告訴你去做什麼產品，但它可以幫你確定實現產品時的哪個細微版本更能揪住使用者大爺們的心.
⒌ 遠離時間吞噬者
剛進Facebook做工程師的時候，我非常享受那種日夜泡在碼海中的感覺。後來慢慢的承擔的專案責任越來越大越來越多，寫程式碼的時間越來越少(但絕大多數時候仍佔大頭). 有時候更多的是把時間花在決定產品的方向和設計上。很多事情是和產品經理設計人員一起搞的. 但在Facebook攻城獅們有很大的發言權甚至有些時候是拍板的權力。Facebook希望攻城獅們有王者風範. Facebook希望攻城獅能決定自己要做什麼應該做什麼, 而不是總是”被決定”做什麼(一種流行的說法是，write your own job description). 因此，我花了大量的時間在思考這些問題 – 哪些功能需要新增，哪些功能需要刪掉，需要開始或停掉哪些測試，我們正在流血流汗的是不是現在最最最重要的問題, 我們是該花時間優化使用者互動流程呢, 還是減少出錯率, 還是讓系統更快, 等等。這些問題很傷腦筋, 答案經常不確定, 比一個勁碼到手抽筋要難. 但這些問題很重要, 甚至可能決定了你熬的日日夜夜究竟有沒有必要. 建議所有的攻城獅思考思考程式碼之外的這些問題, 團隊領導者就更有必要了. 當然, 攻城獅的大多數時間還是應該花在程式碼上.
那究竟哪些時間不應該被浪費呢？
很多, 但我只舉兩個我認為最重要的例子。
郵件。不是所有郵件都發而平等。有些郵件純粹打醬油的. 有些郵件是不需要馬上處理的. 我嘗試使用過濾規則來踢掉打醬油的郵件, 突出需要馬上處理的重要郵件。對此，分享兩點。
1) 建立一個適合你的郵件過濾系統. 我會對重要和緊急的郵件做即刻回覆，而暫緩處理那些可以等到晚上再回復的郵件（尤其是發自我自己的團隊，產品經理，兄弟連和頂頭的不頂頭的上司們的郵件）。但是，我要確保在我掙扎的爬到床上之前，把這些郵件全部處理掉, 讀的讀, 回的回。對於那些僅供參考的郵件，過濾系統會將其塞到某個固定的角落，我隔三差五去瞅瞅。此類郵件諸如某酒鬼詢問Napa Valley哪個酒窖比較正點等等. 這些郵件通常比較有趣, 挖的坑很大很深所以也很耗時間, 我通常不跳或者不馬上跳。
2) 廣而告之你的個人郵件處理策略. 我讓我身邊的戰友們知道我是如何處理郵件的, 並把這個政策放到我所有的郵件末端。如是說 – “正在嘗試個人郵件處理策略-為了戒掉Email癮, 我將強迫自己每隔三小時或以上檢視一次Email，急事請電話/簡訊/IM我” 這麼做更多的是讓別人明白不要指望馬上得到回應. 其實我查email比每3小時要頻繁, 但至少不用馬上逼得去回每個email了, 我可以憋著悠著點. 因為如果真的很急, 我的iPhone應該已經響過了. 而且, 批量處理真的效率要高很多. 不騙你.
會議。開會太容易變成一群人互相在扯對方的蛋. 浪費時間而且開完後發現沒有結論且很蛋疼. 但開會對於teamwork很多時候是必要的. 如何主持會議是門學問, 這裡不細談. 不過, 你不可能也不需要參加每個邀請你的會議。當你認為你參加某會議於己於人都無太多價值的時候, 建議你考慮不去。如果想要有禮貌一點, 那就寫個email問問主持人你是否可以缺席. 通常當你想過這個問題決定發這樣的郵件時，答案通常都會是yes。有些時候我也會很可恥的讓我的產品經理替我去開會。當然，我會鼓勵他也爭取不要去。Only make the meetings you really have to. 同樣, 我要求我自己的團隊在組織和參加會議的時候要慎重，也經常問他們想想看自己花在會議上的時間是不是多了。一個做法是把可能的會議都整合在一起。有一個例子。早些時候, 我們會經常收到來自支援團隊的比較隨意的會面請求。這讓攻城獅的一天被會議分割得支離破碎. 寫程式碼的都知道沒有3-4個小時的連續時間是不容易高潮的. 而且這種會議通常效率很低. 於是，我們改變了做法，每週安排固定的答疑時間(office hour)和支援團隊嗑想法然後follow up。當然, 緊急的問題另當別論應當馬上處理.
有一個被經常忽略的原則 – 有意識地去思考哪些事情不應該做並且馬上不做。例如，哪些是無謂的爭論可以避免介入(比如韓寒和方舟子的 – 個人意見)，哪些功能可以放棄，哪些關係不應該發展, 哪些人應該開掉, 等等。我經常問自己一個很簡單的問題，我現在正在做的是否對我的目標很重要。如果你清楚自己正在做的和自己想要的，答案會明瞭。Go for it.
⒍ 喜愛能有效地降低人們間的緊張
工程師和支援團隊之間有著糾結的合作競爭關係(注意, 合作在前)。網際網路技術公司中很多人(尤其是聰明人)總是期望工程師對所有問題給出一個讓人會心一笑的解決方案。但現實是，不是每一個問題都可以或者應該在技術框架下解決。對於一些具體的問題, 客戶支援和運營部門會有一些非常深刻獨到的見解. 工程師未必行. 畢竟很多見解需要不同的專業知識, 依靠實地經驗。沒錯, 工程師可以在程式碼中自動log大量的原始資料，但從原始資料中提煉可靠的insight卻並不總能如願. 就像大鍊鋼年代扔進去的是鐵, 出來的是鐵疙瘩, 而非期望的鋼. 和很多其他公司的客戶或支援部門不同, 我們的支援部門招募了質量相當好的員工(很多來自美國名校 – 在我直接接觸的反欺詐支援組20來人中就有3名史丹佛校友)。因此，當兩群都很聰明的人觀點相左時，該聽誰的呢? 緊張關係再所難免。
不同的工程師團隊也存在著合作競爭關係。 反垃圾郵件、安全和反欺詐（我的團隊）這幾個團隊之間存在密切的工作協作關係。這些團隊也都儘可能地相互學習，分享經驗和技術。但是，有時候各團隊獨立處理類似但不同的一些問題時，都試圖向對方推銷自己的解決方案和理念。
如何讓合作競爭保持在一種健康有序的狀態? 我覺得關鍵是促進人與人之間的親密感。把人搞近了, 事情就容易了. 我花大量時間用在建立和其他團隊的關係上面。例如兩週一次或者一月一次和其他團隊老大們的1對1碰頭會。越相關的團隊, 頭碰得越頻繁. 我自己或者我的團隊成員會有選擇性的經常參加一些其他團隊的會議 (我們稱之為Friends & Family meeting)。當為一個共同的大專案工作時，我曾安排不同的部門成員（工程師、支援、資料分析、金融財務）坐到一起進行專案衝刺。這是拉近相互之間距離的非常有效的一個做法, 尤其對於減少扯皮的機會. 因為互相之間經常會請或被請喝咖啡. 我也會經常和一些人約定吃工作午餐, 經常聊的是家常, 增的是感情。有的時候一次長距離的散步也更能讓人暢所欲言。而這樣的緊密關係，在我們面對一個極具挑戰性的專案的關鍵時刻，會幫助大家緊緊的抱團闖關.
⒎ 託付並使之生效
分配任務委託別人的重要性比較容易理解. 因為你不是超人, 不能端茶倒水什麼都做吃喝拉撒什麼都管. 有些時候, 你往往還不是最適合的人選. 當團隊一大事情一多, 你一定要學會委託別人來負責合適的任務. 對有些領導者而言, 委託別人一個重要的目標可能不是很放心, 覺都睡不好; 但我非常習慣委託別人, 有時候可能太習慣了. 這是我一位前老闆給我指出來的一個問題. 有一次我給一位組員分配了一個既有技術難度又有協調挑戰的難題. 程式比較緩慢. 但我給了他太多的時間空間來折騰, 而事實上他在某些方面需要一些加強, 有些方面需要我更多的主動的幫助. 我老闆指出來, 如果我要讓別人隨便折騰的話, 前提是我需要有足夠的信心.
如果你有一個重要的任務需要委託給別人, 你要麼
1) 已經對此人非常瞭解. 知道他戰鬥力非凡可以搞定; 或者相信他可以迅速學習提高打雞血搞定;
要麼
2) 需要在一開始手把手教他, 時不時問他, 直到你對他有足夠的信心.
具體我是這麼做的. 專案開始時, 我讓被委託人給我一個整體計劃以及幾天內可以完成的任務. 一開始經常會面跟進, 然後確定後幾天的任務. 根據每次完成狀況來估計他能不能”高快狠”地完成最終的目標. 信心逐漸建成後可以減少關於該專案的細節討論. 此時的委託可以放得更開. 但有一點要注意, 如果跟的太緊的話, 可能讓人覺得你對他不放心, 他也會做得畏首畏尾, 這可能比盲目的委託還更差.
我覺得在這一點上我還要加強. 這裡也和大家提個醒.
⒏反饋是一個持續過程，不是一個一年一兩次的事件
一年一度或兩度的意見反饋在矽谷公司是非常常見的. 它的目的不是設定起來給員工難堪, 讓他們互相責難的. 它的目的是希望員工對自己對他人有更全面的認識, 以助進步. 意見反饋有自我反饋和同事反饋兩部分. 自我反饋是自己評定自己, 完成了哪些目標, 錯失了哪些目標, 哪些方面做好了, 哪些方面還待進步. 但由於是自己踢球兼裁判, 難免有偏頗. 同事反饋, 就像一枚鏡子, 讓你看到180度之外的自己. 在Facebook, 360度的正式意見反饋是一年兩次, 並且和薪酬掛鉤. 但近年來, 意見反饋和薪酬評定逐漸分開. 比如我做的一件事就是季度性的意見反饋, 時間和正式評定錯開. 在那幾天中, 我請求所有相關組的同事在自願的前提下給我寫寫關於我直屬組員的意見反饋, 短短几句都行. 我會收集, 綜合, 最後在1-1碰頭會時反饋給我的組員.
如果需要等半年才來收集意見的話, 很多相關故事早以忘得一乾二淨. 故事越久遠, 記憶越模糊, 意見越空洞, 說了等於沒說. 而且, 意見反饋和薪酬綁在一起, 正常人(即使是牛人)都會很自然的把心眼更多的放到薪酬上, 而不是意見本身.
除了季度性的輕型意見反饋, 日常的意見反饋如果有的話應當立馬傳遞. 趁熱打鐵效果更好.
如何有效傳遞整理好的意見也很重要. 有句話是說”it’s not what you say that matters, it’s how you say it“. 我沒那麼極端, 我覺得如何傳遞意見也同樣重要. 有兩種方式我都試過, 不確定哪種更有效. 這裡都談一談. 一種是以問為主逐漸深入促其思考, 比如”how did you think about the meeting you hosted yesterday”; 另外一種是赤裸裸的直入主題, “hey, let’s talk about the meeting you held yesterday”, 然後開始談我自己的感覺. 不管哪種方式, 一定要給對方一個解釋自己行為的機會; 永遠假設並告訴他我相信他的意願是好的. 為了避免陷入”你昨天做了xxx” “沒有, 我做的是yyy” “我覺你是做了xxx”的死迴圈式的爭論, 我首先爭取和他們在”我們感知的即是事實”這一點上達成共識. 基於這點前提, 我們把討論的重點放在如何做能改變別人的感受最後讓事情能順利完成, 畢竟大多數重要的事都有很多人一同協作完成. 當他們認識到自己想要改進某個方面的時候, 如何改是一個相對容易很多的問題 – 聰明人一向能夠找出改進的辦法, 我所做的就是配合他們做頭腦風暴. 最終談話的目的是產生一個下次如何能做的更好的具體方案.
關於有效傳遞意見反饋, 另有4點提一下.
1) 意見反饋不見得都是負面的. 它可以是別人的一個長處. 你很欣賞. 你希望他這方面堅持做, 做得更多. 比如一句”hey, I really love your weekly summary email with the key metrics at the top. Please keep them coming”可能產生很好的激勵效果.
2) 意見反饋必須擺事實和講道理. 如果你只是告訴別人他很爛, 但不說什麼時候浪過了以及為什麼, 除了給他添點火氣之外無他用. 所以我在相關人員包括自己寫意見反饋的時候要求提供例項. 比如一句 “I think he could make meetings transparent and shorter by having an agenda, like the weekly data review meeting on last Friday”比”his meeting is too long”更有血有肉有效.
3) 意見反饋必須是可操作的. 讓人無從下手的意見意義不大. 如果在提意見的同時提出一個方案以供參考就有意義的多. 但注意, 絕不能是命令的方式 (那是中青寶…). 比如前面的例子”I think he could make meetings transparent and shorter by having an agenda sent ahead of time…”就很容易操作.
4) (個人偏好) 在最近的兩個評價週期中, 我給15個左右的同事(一半不直屬我)寫過意見反饋. 我把我寫的直接分享給他們. 出於這種想法, 在我下筆時就少了很多衝動. 因為他們會讀, 所以我無法做到背後捅刀. 因為他們要讀, 所以我需要寫得有意義, 容易理解, 並且加上很多例子. 並且, 我歡迎他們和我直接討論. 如此一來, 他們也明白我寫這些反饋的一片苦心是為了他們進步.
⒐你能幹得比你想像的多
這不是說說而已. 我自己就有一個親身的例子. 我們曾經認為把一個高得離譜的欺詐率降到所允許的範圍內會很難. 的確很難. 但想想看我們最終牛逼了一把, 把它降到了比允許上限的一半還要低. 感覺很爽. 很長一段時間內整個團隊士氣高昂信心爆棚做事像開了外掛.
牛人們總是不斷的超越自己. 給他們一個離譜的目標, 配以應有的工具, 適當的幫助, 足夠的信心還有一定的時間, 他們會讓你大吃一驚, 也會讓自己大吃一驚. 這一點, 喬幫主是行家, 屢試不爽.
但做到這一點有一個前提 – 不能害怕犯錯. 如果犯錯是被要嚴懲的失敗是不允許的話, 牛人們只能在框框中被圈養, 沒有辦法實現突破. 有一句話我經常掛在嘴上”ask for forgiveness, not for permission“. 在Facebook, 大膽行事犯錯是容易被原諒的.
但反過來, 有一點要小心, 就像第7點所說的 – 你不能隨便把一個離譜的目標交給一個人, 然後期待他來給你驚喜. 盲目帶來的可能是驚嚇. 你需要真正的牛人, 至少是潛在牛人. 而作為一個領導者, 你的一個任務是幫助他們, 鼓勵他們, 來引爆自己的潛力點. Facebook不缺此類待引爆的牛人.
10 不要過度設計和過早樂觀
有些工程師有一股出於本能的衝動想把自己的程式規模化, 甚至在這些程式還沒看到大規模使用的曙光之前. 我在Facebook開始的時候, 也是衝動型工程師一杯. 但經歷過幾次失敗的產品之後, 我牢記了這個教訓. 不要過多設計或者過早優化. 把核心功能設計的簡單精煉. 只有在看到產品有被大規模使用的趨勢後, 才來增加功能或增加規模量. 有一個我做的產品使用的上限是200萬月使用者(當時Facebook整個月使用者群是4000萬左右), 但我的實現已經做了很多額外的功來滿足更多的使用者. 做的時候感覺很爽(感覺自己很牛, 感覺再多人用產品也不會崩潰), 之後感覺很慘.
但這一點不一定能適用於架構上的工作. 比如Friendster這個網站的失敗就是其基礎架構的效能長期無法應對急速增長的使用者以致網站很慢甚至崩潰.在使用者增長高潮來臨之前,
—————————–
在Facebook的4年半很好玩. 我學到的感受到的遠多於以上的十項. 但希望這個分享能對朋友們有點幫助. 同時祝所有的朋友在自己現在扮演的角色上都有好運.
此外, 如果你是一位創業者, 並且認同以上的某些觀點, 我很歡迎你通過一個共同的朋友來介紹自己. 我會很樂意給出我的建議, 不管是在產品上技術上還是管理上. 如果機會合適的話, 參與早期的天使投資. 投資不多, 但你可能收穫一個有點經驗的免費顧問 :)