那究竟哪些時間不應該被浪費呢？
很多，但我只舉兩個我認為最重要的例子。
郵件。不是所有郵件都發而平等。有些郵件純粹打醬油的。有些郵件是不需要馬上處理的。我嘗試使用過濾規則來踢掉打醬油的郵件，突出需要馬上處理的重要郵件。對此，分享兩點。
建立一個適合你的郵件過濾系統。我會對重要和緊急的郵件做即刻回復，而暫緩處理那些可以等到晚上再回復的郵件。但是，我要確保在我掙扎的爬到床上之前，把這些郵件全部處理掉，讀的讀，回的回。對於那些僅供參考的郵件，過濾系統會將其塞到某個固定的角落，我隔三差五去瞅瞅。此類郵件諸如某酒鬼詢問napavalley哪個酒窖比較正點等等。這些郵件通常比較有趣，挖的坑很大很深所以也很耗時間，我通常不跳或者不馬上跳。
廣而告之你的個人郵件處理策略。我讓我身邊的戰友們知道我是如何處理郵件的，並把這個政策放到我所有的郵件末端。如是說–“正在嘗試個人郵件處理策略-為了戒掉email癮，我將強迫自己每隔三小時或以上查看一次email，急事請電話/簡訊/im我”這么做更多的是讓別人明白不要指望馬上得到回應。其實我查email比每3小時要頻繁，但至少不用馬上逼得去回每個email了，我可以憋著悠著點。因為如果真的很急，我的iphone應該已經響過了。而且，批量處理真的效率要高很多。不騙你。
會議。開會太容易變成一群人互相在扯對方的蛋。浪費時間而且開完後發現沒有結論且很蛋疼。但開會對於teamwork很多時候是必要的。如何主持會議是門學問，這裡不細談。不過，你不可能也不需要參加每個邀請你的會議。當你認為你參加某會議於己於人都無太多價值的時候，建議你考慮不去。如果想要有禮貌一點，那就寫個email問問主持人你是否可以缺席。通常當你想過這個問題決定發這樣的郵件時，答案通常都會是yes。有些時候我也會很可恥的讓我的產品經理替我去開會。當然，我會鼓勵他也爭取不要去。only make the meetings you really have to。同樣，我要求我自己的團隊在組織和參加會議的時候要慎重，也經常問他們想想看自己花在會議上的時間是不是多了。一個做法是把可能的會議都整合在一起。有一個例子。早些時候，我們會經常收到來自支持團隊的比較隨意的會面請求。這讓攻城獅的一天被會議分割得支離破碎。寫代碼的都知道沒有3-4個小時的連續時間是不容易高潮的。而且這種會議通常效率很低。於是，我們改變了做法，每周安排固定的答疑時間和支持團隊嗑想法然後follow up。當然，緊急的問題另當別論應當馬上處理。
有一個被經常忽略的原則–有意識地去思考哪些事情不應該做並且馬上不做。例如，哪些是無謂的爭論可以避免介入，哪些功能可以放棄，哪些關係不應該發展，哪些人應該開掉，等等。我經常問自己一個很簡單的問題，我現在正在做的是否對我的目標很重要。如果你清楚自己正在做的和自己想要的，答案會明了。go for it。
6、喜愛能有效地降低人們間的緊張。
工程師和支持團隊之間有著糾結的合作競爭關係。網際網路技術公司中很多人總是期望工程師對所有問題給出一個讓人會心一笑的解決方案。但現實是，不是每一個問題都可以或者應該在技術框架下解決。對於一些具體的問題，客戶支持和運營部門會有一些非常深刻獨到的見解。工程師未必行。畢竟很多見解需要不同的專業知識，依靠實地經驗。沒錯，工程師可以在代碼中自動log大量的原始數據，但從原始數據中提煉可靠的insight卻並不總能如願。就像大煉鋼年代扔進去的是鐵，出來的是鐵疙瘩，而非期望的鋼。和很多其他公司的客戶或支持部門不同，我們的支持部門招募了質量相當好的員工。因此，當兩群都很聰明的人觀點相左時，該聽誰的呢？緊張關係再所難免。