[The Effective Engineer 筆記] Focus on High-Leverage Activities
這是 Adopt the right mindset 下的第一章，也是整本書的核心概念：隨時專注在 high leverage 的活動。所以什麼是 leverage 呢？ leverage (n.) 槓桿作用、利用。嗯好像還是完全不懂，讓我們來看看作者的定義
白話的說即是，一段時間的影響力。這個公式有兩個重點，第一個即為分母，時間。作者的用意並不是你要花更多時間完成更多事，相反的，花越少時間完成leverage 越高，要思考如何用一定、甚至最少的時間完成最有影響力的事，因為時間是最寶貴且最有限的資源。第二個重點為分子，即影響力(Impact produced)，在我的理解中他並不單純是產出，畢竟產出 ≠ 影響力。舉個簡單的例子，你可能花了很多的時間做出了一個很厲害的產品，但是沒有半個客戶買單。也就是說你的產出看似很高，但影響力其實是0。其實這就是ROI (Return on Investment) 投資報酬率的概念，如何用有限的投資(時間)，換取最高的報酬(影響力)
舉個例子，作者在本章一開始提到的 mentor 和 on-board program (帶領新人如何快速上手的program)，就是非常高leverage 的活動。或許會有人認為，帶新人完全是浪費時間，自己也不會有產出。但以公司的角度來看，一個工程師一年大概有1880–2820工時，假設帶一個新人需要花資深工程師20小時，也就是說只要花20小時，就增加了1880–2820小時的產值，其實是非常有影響力的事情
如何增加 leverage
- 減少完成活動的時間(即降低分母)
- 增加這個活動的影響力(即增加分子)
- 把時間花在更高 leverage 的活動上
隨時問自己三個問題
- 要怎麼用更少的時間完成這件事
- 要怎麼增加這件事的影響力
- 有什麼更高leverage 的事值得去做
身為工程師，我們每天的行程可能如下
這邊可以看到每個活動對應到大致的leverage，那麼我們如何提高leverage 呢？作者在這邊也舉出了三個例子
每天一小時的會議可能是必要的，但是如何讓他更有效率呢？我們可以
- 試著把開會時間減半，看能否在半小時內完成
- 事前準備議程，並設定會議目標
- 如果有些問題不是那麼重要，可以移到emai/slack 上面討論，把會議時間留給更重要的事情
假設你是一位產品經理 (product manager)，準備開發一個面向客戶的新功能，你可以
- 自動化某些開發和測試，這樣可以迭代的更快
- 對每個任務排序(prioritize the task)，對上線重要的功能先做
- 跟客服聊聊，多瞭解客戶的痛點，去思考有沒有別的功能是必要而且更重要的
假設你是一個 performance engineer，負責查看公司網頁有哪些瓶頸(bottleneck)，並確保公司網頁讀取的速度夠快，你可以
- 學習用一些效能分析工具，減少找出 bottleneck 的時間
- 測試每個網頁的效能和流量，流量高的先做
- 跟 product team 合作，把效能當成重要的指標，而不是 bug 來修
本章小記
- 用 leverage 去衡量你的效率
- 系統性地去思考如何增加 leverage ，隨時問自己那三個問題
- 時間是最寶貴的資產，所以要隨時專注在高 leverage 的活動
