最近有比較多的機會在 1 on 1 coaching 一些很有潛力的工程師，
他們都擁有不錯的特質，技能平均也都高於同年資的同儕，
但他們對自己的職涯感到茫然，
因為他們絕大部分都熱愛技術，卻又對技術這條路能走多遠感到徬徨。
他們都想變強，但又不太清楚可以怎麼鍛鍊自己的能力。
技術，絕對不只是寫程式。
寫程式，也絕對不是只有「拿規格、寫程式」，
就像那句有名的話「programming is thinking, not typing.」
決定絕對薪資的因素，就如同版上很多文章所說，權重大概類似這樣：
國家（物價）> 公司 = 公司賺錢程度 > 個人技能/創造價值 > 年資 = 語言
能自己決定，且比較有意義的部分，還是在個人技能，以及如何創造出公司需要的價值。
在 1 on 1 的過程，我幾乎都會提及，要往 tech leader 走，
我覺得可以透過技術提案來鍛鍊自己的能力、視野，
讓你學習的知識落地，真正在實務上替公司、團隊、產品帶來價值。
我整理了一篇文章，文章傳送門：http://bit.ly/tech-proposal
【文章摘要】
1. 向外取經
包含參加社群活動、研討會、培訓、邀請教練、有效閱讀。
重點在於，向外取經之後的反思與行動。
沒有引起變化的取經，都只是心靈雞湯，暖暖的，但嚴格來說是浪費時間。
2. 新的解決方案，其存在的意義為何？
新的解決方案通常都是在某個主題、領域，比起其他解決方案更加優雅。
反思這個新的解決方案，要解決的問題本質是什麼？
我們現在是否存在著相同的問題？或是可見的未來是否可能發生同樣的問題？
要避免「一窩蜂驅動開發」的衝動。
3. 我們現在是怎麼做的？
反問自己：
- 我們現在是怎麼做的？
- 付出的代價是什麼？
- 達到的效益如何？
- 是否已符合我們的期待？我們的期待為何？
先定義問題，才能解決問題。確認期望，才能評估是否有效。
4. 比較方案
我們不會是第一個碰到這問題，或是只有我們有這樣的需求。
- 調研一下這個問題或需求，有哪些其他的解決方案
- 各自的優缺點與適用場景
- 動手設計一些範例、雛形，進行概念驗證（POC）
5. 提出建議方案
基於我們公司、團隊、產品、環境、流程、組織與文化等等，建議採用哪一個方案，並說
明為什麼？應包含預計需付出的成本、風險、影響範圍、帶來的效益、需要的時間、前置
作業以及必要條件。
6. 引入變革的行動規劃
如果要開始試用與導入，可以從哪邊開始？為什麼？
規劃應包含：
- 先從哪一個專案、團隊或功能比較合適？為什麼？
- 預計何時開始？需要多久？檢核點的日期？
- 哪些人合適當首批引入與配合變革的人？
- 如何評估效益？
- 如何制訂政策來鼓勵加入變革的同仁？
- 你需要什麼樣的 support 跟 resource？
==========================================================
以上只是個人的經驗與淺見，透過不斷練習這樣的過程，
一來可以保持自己接觸外界新知，
二來確保學習知識能進行知識螺旋的轉化過程，進而引發變化、行動，以試圖產生價值，
三來累積自己在團隊的影響力，引領變革，並站在公司、產品、團隊的價值優先。
這是 tech leader 自己一個很重要的學習模型，也是產品與團隊需要的幫助，也是公司
所需要的專業價值。
這一整串的過程，是鍛鍊自己內外軟硬技能很好的方式，不管最後是成功或失敗了，
累積在自己身上的能力經驗不會消失。
而公司也需要在風險可控的情況下，嘗試一些 DNA 的突破，才能獲得本質性的提昇。
如果您已經在很賺錢的一流公司中，但薪資已經達到天花板了，
而你也有想學習跟變強的衝動，或許這可以提供您多一個角度來嘗試變強和創造價值。