最近挺多工程師詢問到，要成為一位 tech leader 該具備哪些技能，該怎麼樣培養自己的能力呢？
這問題當然是個大哉問，也沒有所謂的正確解答。但我總會建議他們：「要讓自己往 tech leader 前進，你應該要養成提供技術提案的能力。並透過這個方式，不斷鍛鍊自己。」
如果在學習知識的過程中，撰寫 blog 文章是內化外顯知識的核心，那麼技術提案，也就是 proposal，我認為是自我學習跟在公司內創造價值中間的橋樑，也是讓知識落地、務實、導入的起點。
向外取經
公司內部軟體開發，往往會慢慢趨向於穩定，因為穩定可以降低學習成本、減少風險，基於不變的情況下提昇效率（效率不等於效果）。
然而，如果工程師的學習來源僅限於公司內部，那公司與個人的進步，就會停滯不前了。這也是常被稱為「活在自己井裡」、「一年的經驗重複 N 次」的情況。要帶領公司跟團隊前進，tech leader 得不斷補充活水，向外取經學習，才能引入變革。
向外取經的渠道包含以下幾種。
1. 參加社群活動
社群活動往往是主題內聚含量極高的活動，不一定只能從主講人身上學到東西，很多時候從與會人員身上也可以挖到不少難能可貴的經驗來借鏡。另外，不論技術好壞，這群參與者肯定都有一定的技術熱情與學習心。建立這樣的 connection 不論對自己或是公司，都可以有所幫助。
2. 參加研討會
研討會的議題通常與潮流和技術趨勢比較相關，想要聽到新的應用、工具、框架，研討會也不失為一種方式。但我個人認為，研討會因為形式往往是演講跟演示，較少互動（除非有 Open Space 或講師面對面的安排），就不容易深入主題，只能當作開視野、聽新知的機會。
3. 參加培訓
根據經驗，自費的效果往往比公司補助來得有效許多，不論是動機、熱情、預習/練習/複習，都特別有效果。參加培訓，一定是對某個主題領域有興趣，或是實務上碰到一些問題，也就是一定能帶著目的性去。
4. 邀請教練
如果公司有請外部的顧問或技術教練，盡可能增加跟教練一起貼身肉搏的機會，那種只出一張嘴的顧問跟教練，就不太需要跟他浪費時間。真正的技術教練是要能跟你一起進行實務的任務，貼身肉搏，拳拳到肉。
5. 有效閱讀
書跟文章是看不完的，因為書跟文章的產生速度遠高於你的閱讀、理解、消化速度，而且品質不好的內容，可能導致沒有分辨能力的人理解錯誤，有分辨能力的人則是浪費時間。所以書該怎麼挑，書該怎麼看，我提供一些個人的經驗：
- 加入該主題相關的社群、活動：例如從線上的社群交流與活動，能瞭解哪一些人是特別有熱情的，哪一些人是該領域的專家，他們常在論壇、社群/社團中發聲，不管是推薦學習資源、分享新知、拋出開放性的問題引發討論，或是針對別人的疑問提供見解。可以嘗試著從別人的討論串開始嘗試一些互動。
- 請教社群提供學習的建議：描述清楚你的 context，例如你的學習目的、你目前在該領域的熟悉程度，已經自己看過學習過哪些東西，以及你打算在哪運用。請大家依據你的 context 提供適合的學習資源與方式給你。不要輕忽了描述你 context 的重要性，因為學習都是由淺入深的，每個人狀態不同，自然推薦給他的學習建議就該不一樣，才會有效。由這些社群專家跟先驅者來幫你過濾、篩選、推薦，可以節省你走很多冤枉路的時間跟成本，因為在這個資訊爆炸的時代，應該先花時間在高品質的內容中。
有了社群幫忙推薦跟過濾後的切入點，接著就該進行點、線、面的學習。
如果是有品質的文章，通常文章中或 blog 上，會額外推薦一些相關文章或網站的連結。如果這篇文章品質是好的，往往它所推薦的其他資源也都是寫得不錯的，記得往外延伸挖寶，通常寶藏都是在這過程中發現的。
如果是書籍，我建議你可以到 Amazon 上搜尋一下，買了該書的人，同時還買了哪些書或對哪些書有興趣。該作者除了這本書以外，還有出哪幾本書。該作者除了自己的書以外，還幫哪些書寫過推薦序。
我自己看書的方式，先從社群的專家依據我的 context 推薦值得學習的經典書開始，我會同時把該領域評價不錯的書都一併買下來，我看書向來不死守著「一本書看完才換下一本」的規矩。原因是：
- 如果我買的書品質都是很不錯的，通常書的脈絡跟組織，都是由淺入深的。當我看第一本書到某個主題卡住時，我會先努力試著理解，尋找相關資源，如果無法突破，我就會跳過這本書，改看該領域別本書。當看某本書卡住看不懂時，有可能是作者跟你的 context 不一樣或差異很大，所以他說明的方式、舉個例子，你沒有感覺，不容易理解。也有可能是因為你少了某些前置知識點，所以知識銜接不起來。
- 這時改看同領域別本經典書，前面你已經知道的部分，通常可以看很快，而把精力花在你不知道的部分。有可能因為別本書而補足了你的前置知識點，而且換個作者來解釋概念，就像另外一個老師換另外的例子與方式來跟你解說同一個觀念，要突破知識瓶頸往往就會容易一些。
取經完，Then?
不論參加了幾場社群活動、研討會、培訓活動，看了多少文章或幾本書，重點在於：然後呢？很多人就沒有然後了。
很多人取經完之後，都以為自己多學到了一些知識，事實上這只是喝了心靈雞湯之後的飽足感罷了。其實聽的時候好棒棒，聽完當下嗨了一下，接著大腦過一陣子就代謝掉這段記憶了。
也有些人取經之後，回到公司跟團隊，參考活動的簡報、講義，依樣畫葫蘆的分享給其他人，其實只是拾人牙慧，為了交代而分享，並不足以構成價值跟促使變化。
那麼該反思哪些東西呢？
新的解決方案所存在的意義？
解決方案包括了方法論、工具、框架跟某類模式，而這些東西之所以存在或是受到注目，通常都是因為它的本質可以幫助解決某一類型的問題，在某些限制、前提、環境下，它解決問題的方式比較優雅。例如：學習門檻比較低、可讀性與維護性比較好、效能比較快、生產力比較高等等…
需求或問題的存在是中性的，推陳出新的解決方案往往是針對某個特定問題與應用來最佳化。當我們關注這個新的解決方案，要避免只是為了潮、為了新，而是該回顧它存在的本質，是為了解決什麼樣的問題，滿足什麼樣的需求。
而我們的公司、產品、團隊、流程，目前是否存在著這樣的問題？未來會不會發生這樣的問題？這才是引入活水關鍵的起手式，如果沒有價值導向，那所有的變革都是徒增成本跟困擾。
我們現在是怎麼做的？
如果我們現在也面臨這樣的問題，或是可見的未來也可能會發生這樣的問題，那麼自己試著回答下列問題：
- 我們現在是怎麼做的？
- 付出的代價是什麼？
- 達到的效益如何？
- 是否已符合我們的期待？我們的期待為何？
先定義問題，才能解決問題。確認期望，才能評估是否有效。
比較方案
同樣的需求與問題，除了新引入的解決方案以及我們現行的作法外，這個世界還有哪一些方式可以解決這類的問題呢？
- 調研一下這個問題或需求，有哪些其他的解決方案
- 各自的優缺點與適用場景
- 動手設計一些範例、雛形，進行概念驗證（POC）
建議方案
基於我們公司、團隊、產品、環境、流程、組織與文化等等，建議採用哪一個方案，並說明為什麼？應包含預計需付出的成本、風險、影響範圍、帶來的效益、需要的時間、前置作業以及必要條件。
引入變革的行動規劃
如果要開始試用與導入，可以從哪邊開始？為什麼？
規劃應包含：
- 先從哪一個專案、團隊或功能比較合適？為什麼？
- 預計何時開始？需要多久？檢核點的日期？
- 哪些人合適當首批引入與配合變革的人？
- 如何評估效益？
- 如何制訂政策來鼓勵加入變革的同仁？
- 你需要什麼樣的 support 跟 resource？
結論
Tech leader 與一般 senior engineer 之間一個最大的差異是：影響力。
Tech leader 得站在公司產品的角度、考量團隊與限制，不斷提昇團隊技能、生產力與產品品質，不一味追求高大上或潮流，而是務實與通盤考量的進行思考、學習、分析、整理、練習，確認價值與可行性，從選擇中挑一個最適當解決方案，迭代式地頻繁進行行動、觀察、調整。
這是 tech leader 自己一個很重要的學習模型，也是產品與團隊需要的幫助，也是公司所需要的專業價值。這一整串的過程，是鍛鍊自己內外軟硬技能很好的方式，不管最後是成功或失敗了，自己身上累積的能力經驗不會消失，而公司也需要在風險可控的情況下，嘗試一些 DNA 的突破，才能獲得本質性的提昇。
我自己很認同 Modern Agile 所推崇的那四點，這四點就是本文所提的技術提案與引入變革所需的基石：
- Make people awesome
- Make safety a prerequisite
- Experiment & learn rapidly
- Deliver value continuously
blog 與課程更新內容，請前往新站位置：http://tdd.best/
