被主管升上 Tech Lead 後我的心情有點複雜，因為職等既沒有對應的提升，也沒有一個實際的稱號，只是被指名了「嘿，從現在開始你就是 Tech Lead」，然後加了一點薪水。
不過對我來說是個很好的嘗試，在這邊記錄一些感想。
Tech Lead 與 Team Lead 的差別
在名詞的定義上我比較傾向於 Tech Lead 而非 Team Lead。
兩者對我來說意義不太相同，一個是單純在技術上跟開發上做領導，一個則是有點偏向管理職還有帶團隊了，我現在的角色比較偏向 1。（當然名詞的定義因人而已，這邊只是點出我的想法）
從開發早期的早期階段，我就算是一個喜歡埋頭寫程式碼的工程師，倒也不是說 spec 什麼的就不去理解，而是比起解決人之間的事情，我更喜歡直接從架構上下手。
這也是我最大的弱點且需要改善的地方之一，就算自己一個人寫很快，但不提升團隊開發速度的話其實沒有什麼太大效果。
為什麼這樣說？假設你完成功能的速度很快、品質好、Bug 也很少；但是你的團員知道這個功能在幹嘛嗎？你的團員跟得上你的腳步嗎？你的團員寫程式碼都是類似的思維嗎？
如果這些問題都是否，那麼你很有可能在開發中後期開始遇到各種不符合 spec、當初沒考慮的 Bug 噴出、被其他團員的程式碼拖慢腳步，最後全部的開發都會卡在 QA。
跟之前的差異
最明顯的差異就是會議變多了，以往只要開發者之間跟 Engineer Manager 內互相討論就好，但是升上 Tech Lead 之後開始要跟各個部門、專案的人合作。以前講英、日文的比例大概是 7:3，現在完全反過來，還好這家公司對敬語不太在意，不然感覺好辛苦。 另外就是大家對你的期望也理所當然越來越高了，任何規格、spec 不清楚的部分第一個就是先找你，所以對規格的掌握就要比其他開發者來得深，也要知道大概會遇到哪些問題給出解決方案。 另外就是寫扣的時間明顯減少了，但其實沒有少很多，而且資料抓出來反而我還是寫最多的那一個，這其實是個不太好的信號，我應該花更多時間去思考如何改善整體流程與團隊運作上，而不是花時間寫程式碼。
事前發現問題比解決問題更重要
我發現比起解決問題，發現問題本身重要更多。在這次的團隊中，我發現潛在問題有幾個：
- 團隊成員相對沒有處理複雜場景的經驗
- 不注重整體流程與程式碼品質
- 不會完全按照（理解）spec 以及與 Planner 溝通可能的潛在場景。
舉例來說，我在開發階段就隱約感受到有一位團員會堅持某些細微的實作細節，雖然這本身是好事，但如果花了兩個月還做不出任何東西，導致時程延誤的時候就是大事了；另外就是對品質與整體流程的不注重，什麼問題都想靠其他團員的 Code Review 來抓錯，導致後來 QA 回報的問題越來越多，整個開發團隊忙得不可開交。
說真的那段時間我很失望，但也反省了很多事情。
- 在開發中沒有所謂的英雄主義，別妄想成員們會一夕之間改變
- 比起程式碼品質（當然這也很重要），先把問題的根源釐清再說
上述提到的問題導致開發後期修 Bug 的成本增加很多，也因為時程的關係每個人情緒都很緊張，也要投入更多時間，整體的品質就會下降很多。也因此比起解決問題，早期發現早期治療這句箴言也應該被當作信條遵守才是。
視團員們準時下班為第一守則
我自己很希望做到的一件事是，讓其他團員們準時下班，在專案上也可以盡情做到想嘗試的事情，但總覺得自己離這樣的理想還有好一段距離。
掌握團員進度很重要
我會升上 Tech Lead 的原因或許是因為在第一季的活躍跟積極度讓主管注意到我，也可能是因為在技術與業務場景處理上比其他團員更有經驗。
但是如果只有自己擅長的話那也沒有用，會自己忙到死，同時也要讓其他成員知道業務場景的重要性以及需求才行。
如果這個團隊存在沒有你就做不到的事，那麼這就不是一個理想的團隊
我相信這個道理，也在上一間公司體驗到類似的事（在上一間公司並非 Tech Lead），當大家幾乎都擁有同樣的價值觀、技術力、個性時，不論經驗或是職位差距，合作起來就會非常順利。不需要特別跑 Scrum，開各種會議，大家就會準時甚至提早交出成果來。
當然這種團隊可遇不可求。所以大部分的時候我會透過在 Daily Meeting 的詢問，讓他們知道該設計的地方有哪些。這是最直接影響 Sprint 產出的要素之一，也是解決問題的好方法。
但這就需要我不僅要顧及自己的開發進度，同時也要對整體的架構、規格非常熟悉，才能知道可能的問題有哪些。
理解自己的優劣勢
我非常不擅長於說教跟改變一個人，也不是容易跟人打成一片的個性，所以一旦我希望成員做到某些事情，口氣往往聽起來會有點激進。
我完全無法忍受有人偷懶拖慢團隊進度，當上 Lead 之後開始會追蹤各個團員的進度，我發現當中有一位成員在提交的 Pull Request 以及 Code Review 上是明顯小於其他成員的（大約 2 倍以上）。我試過很多方法，包含在 Code Review 上積極點出錯誤、在 Slack 上提點細節、對於延誤沒回應的 Pull Request 做詢問，但如果對方都不改善的話，我其實也沒有任何職權做什麼就是了。
找到 Blocker 指標
對我來說有幾個指標是要特別注意的
- 複雜且有大量更動的 Pull Request：這很有可能會是 QA Issues 的主要觸發區，所以要確保測試通過還有開發人員的一致理解。
- 在 Sprint 結束前的 Task 數量：很多開發人員不會特別在意。如果他們有非常多 Working In Progress 的 Task，可以詢問一下他們的進度。如果太常發生類似的狀況，代表團隊中有人超載
- 過度或不適當的重構：我們應該要避免不適當或是過度的重構，如果重構破壞了原有架構，會讓 QA Issues 非減反增，反而得不償失。
- 用指標來評估團隊效率：Code Review 時間、Pull Request 數量、一個 feature 從開發後到 merge deploy 要多久？
- 有團員一直卡在某個 Issue 上，沒有任何詢問。往往是他們卡關又沒有發出求救信號
要深究下去還有很多，這裡只講我想到覺得很重要的幾點。
後記
老實說我還是有點迷惘，一方面是我在這裡遇到的開發者，比起以往的同事對於技術比較沒有那麼熱衷，很多時候都是求任務完成就好。也不會特別在意開發流程或其他改善，這是讓我非常沮喪的地方。而主管也認為我應該要去幫助他們，多多體諒文化差異。
但如果一個人不願意改變，然後做了各種影響團隊產出跟動機的事，為什麼要被譴責的是我而不是他？還要用我的績效考核來陪葬？還是用文化差異就可以無限上綱到蹺班不工作也沒關係？
另一方面，我並沒有實際的職權去做人力、資源的調整，頂多就是把問題再丟給上層而已，這次的開發不僅時程緊湊，加上各種經驗的不熟稔和人力的調整過於緩慢，導致整個開發根本沒有什麼時間在做真正應該處理的事，我也根本無力改變什麼。
當上 Tech Lead 之後的確也開啟我不少視野，以往跟非工程師的交流並不多，但現在幾乎每天都要頻繁跟跟 Planner 協商、討論各種 Spec 上的細節，東京人不知道為什麼講日文要快兩倍，讓我日文瞬間進步不少，也學了一大堆業務用日文。 很多時候只要從公司的角度出發去想規格就可以解決很多問題，在交涉的時候也只要想辦法解決他們的問題，雙方的僵持就不會那麼嚴重。
哎，結果到頭來最大的問題還是人。
更新（2020/06/15）
在文章發布之後，主管有主動跑來找我聊天，解答了一些我在文章中提出的疑問。這篇文章意外地受到蠻多迴響，或許是大家的經驗上都有類似之處而產生共鳴。比較想要補充的一點是，這篇文說到底也只是個人感想的總結，也有可能因為觀點不同而有所偏頗。
另外感謝推友 @brucesu 推薦的文章「breaking the senior developer ceiling」 ，蠻認同文章中的觀點，如果希望繼續往上爬，有時候寫扣已經不是必要，而是專注提供價值更高的事，也要試著多從公司的角度來看。
雖然如此，我自己認為在技術上還是有很多磨練不足、不成熟的地方，因此在這個階段還是想要多技術為主，並且多往架構層面邁進。
