會議。開會太容易變成一群人互相在扯對方的蛋. 浪費時間而且開完后發現沒有結論且很蛋疼. 但開會對于teamwork很多時候是必要的. 如何主持會議是門學問, 這里不細談. 不過, 你不可能也不需要參加每個邀請你的會議。當你認為你參加某會議于己于人都無太多價值的時候, 建議你考慮不去。如果想要有禮貌一點, 那就寫個email問問主持人你是否可以缺席. 通常當你想過這個問題決定發這樣的郵件時,答案通常都會是yes。有些時候我也會很可恥的讓我的產品經理替我去開會。當然,我會鼓勵他也爭取不要去。Only make the meetings you really have to. 同樣, 我要求我自己的團隊在組織和參加會議的時候要慎重,也經常問他們想想看自己花在會議上的時間是不是多了。一個做法是把可能的會議都整合在一起。有一個例子。早些時候, 我們會經常收到來自支持團隊的比較隨意的會面請求。這讓攻城獅的一天被會議分割得支離破碎. 寫代碼的都知道沒有3-4個小時的連續時間是不容易高潮的. 而且這種會議通常效率很低. 于是,我們改變了做法,每周安排固定的答疑時間(office hour)和支持團隊嗑想法然后follow up。當然, 緊急的問題另當別論應當馬上處理.
有一個被經常忽略的原則 - 有意識地去思考哪些事情不應該做并且馬上不做。例如,哪些是無謂的爭論可以避免介入,哪些功能可以放棄,哪些關系不應該發展, 哪些人應該開掉, 等等。我經常問自己一個很簡單的問題,我現在正在做的是否對我的目標很重要。如果你清楚自己正在做的和自己想要的,答案會明了。Go for it.
6
增進親密感是減少緊張關系的有效方式
工程師和支持團隊之間有著糾結的合作競爭關系(注意, 合作在前)?;ヂ摼W技術公司中很多人(尤其是聰明人)總是期望工程師對所有問題給出一個讓人會心一笑的解決方案。但現實是,不是每一個問題都可以或者應該在技術框架下解決。對于一些具體的問題, 客戶支持和運營部門會有一些非常深刻獨到的見解. 工程師未必行. 畢竟很多見解需要不同的專業知識, 依靠實地經驗。沒錯, 工程師可以在代碼中自動log大量的原始數據,但從原始數據中提煉可靠的判斷卻并不總能如愿. 和很多其他公司的客戶或支持部門不同, 我們的支持部門招募了質量相當好的員工(很多來自美國名校 - 在我直接接觸的反欺詐支持組20來人中就有3名斯坦福校友)。因此,當兩群都很聰明的人觀點相左時,該聽誰的呢? 緊張關系再所難免。
不同的工程師團隊也存在著合作競爭關系。 反垃圾郵件、安全和反欺詐(我的團隊)這幾個團隊之間存在密切的工作協作關系。這些團隊也都盡可能地相互學習,分享經驗和技術。但是,有時候各團隊獨立處理類似但不同的一些問題時,都試圖向對方推銷自己的解決方案和理念。
如何讓合作競爭保持在一種健康有序的狀態? 我覺得關鍵是促進人與人之間的親密感。把人搞近了, 事情就容易了. 我花大量時間用在建立和其他團隊的關系上面。例如兩周一次或者一月一次和其他團隊老大們的1對1碰頭會。越相關的團隊, 頭碰得越頻繁. 我自己或者我的團隊成員會有選擇性的經常參加一些其他團隊的會議 (我們稱之為Friends & Family meeting)。當為一個共同的大項目工作時,我曾安排不同的部門成員(工程師、支持、數據分析、金融財務)坐到一起進行項目沖刺。這是拉近相互之間距離的非常有效的一個做法, 尤其對于減少扯皮的機會. 因為互相之間經常會請或被請喝咖啡 (可稱之為"咖啡外交"). 我也會經常和一些人約定吃工作午餐, 經常聊的是家常, 增的是感情。有的時候一次長距離的散步也更能讓人暢所欲言。而這樣的緊密關系,在我們面對一個極具挑戰性的項目的關鍵時刻,會幫助大家緊緊的抱團闖關.
7
習慣委托, 但不要盲目, 請謹慎
分配任務委托別人的重要性比較容易理解. 因為你不是超人, 不能端茶倒水什么都做吃喝拉撒什么都管. 有些時候, 你往往還不是最適合的人選. 當團隊一大事情一多, 你一定要學會委托別人來負責合適的任務. 對有些領導者而言, 委托別人一個重要的目標可能不是很放心, 覺都睡不好; 但我非常習慣委托別人, 有時候可能太習慣了. 這是我一位前老板給我指出來的一個問題. 有一次我給一位組員分配了一個既有技術難度又有協調挑戰的難題. 進程比較緩慢. 但我給了他太多的時間空間來折騰, 而事實上他在某些方面需要一些加強, 有些方面需要我更多的主動的幫助. 我老板指出來, 如果我要讓別人隨便折騰的話, 前提是我需要有足夠的信心. 我需要有事實來逐漸證明我的決定是正確的. 需要謹慎委托. 因為如果項目失敗, 對他而言, 最終負責的人還是我, 不是別人. 所以我不能以別人不行來給失敗的委托埋單.
如果你有一個重要的任務需要委托給別人, 你要么
1) 已經對此人非常了解. 知道他戰斗力非凡可以搞定; 或者相信他可以迅速學習提高打雞血搞定;
要么
2) 需要在一開始手把手教他, 時不時問他, 直到你對他有足夠的信心.
具體我是這么做的. 項目開始時, 我讓被委托人給我一個整體計劃以及幾天內可以完成的任務. 一開始經常會面跟進, 然后確定后幾天的任務. 根據每次完成狀況來估計他能不能"高快狠"地完成最終的目標. 信心逐漸建成后可以減少關于該項目的細節討論. 此時的委托可以放得更開. 但有一點要注意, 如果跟的太緊的話, 可能讓人覺得你對他不放心, 他也會做得畏首畏尾, 這可能比盲目的委托還更差. 所以在委托和謹慎之間, 有一個微妙平衡.
我覺得在這一點上我還要加強. 這里也和大家提個醒.
8
意見反饋應該一個持續性的, 而不是一年一次或兩次的活動
一年一度或兩度的意見反饋在硅谷公司是非常常見的. 它的目的不是設置起來給員工難堪, 讓他們互相責難的. 它的目的是希望員工對自己對他人有更全面的認識, 以助進步. 意見反饋有自我反饋和同事反饋兩部分. 自我反饋是自己評定自己, 完成了哪些目標, 錯失了哪些目標, 哪些方面做好了, 哪些方面還待進步. 但由于是自己踢球兼裁判, 難免有偏頗. 同事反饋, 就像一枚鏡子, 讓你看到180度之外的自己. 在Facebook, 360度的正式意見反饋是一年兩次, 并且和薪酬掛鉤. 但近年來, 意見反饋和薪酬評定逐漸分開. 比如我做的一件事就是季度性的意見反饋, 時間和正式評定錯開. 在那幾天中, 我請求所有相關組的同事在自愿的前提下給我寫寫關于我直屬組員的意見反饋, 短短幾句都行. 我會收集, 綜合, 最后在1-1碰頭會時反饋給我的組員.