# 如何做到真正有效的技術領導：實用技巧篇 - Jocelin Ho

{%hackmd o8oUosN0QnqMSkF1_6kH7g %}

#### 📚 議程介紹

{%preview https://webconf.tw/agenda/30 %}

###### ▼▼▼ 開始筆記 ▼▼▼

## 誰適合聽這場分享
1. 你已經是技術領導者，想知道怎樣能更有效的帶領團隊，達到更好成果
- 想幫助能力已經很好的同事發揮更好
3. 還不是技術領導者，但希望能往這條路前進（Senior）
4. 不是技術背景，對於如何有效領導團隊有興趣

## Jocelin 的背景：Leader Founder Engineer
- PicCollage 2024-now
Engineering Manager
想要在已經成功的新產品上看能不能再加上一些創新的東西
- Cooby 2020-2024
CTO co-founder - CRM 優化工具
- Instagram 2018-2020
Tech Lead - 推出IGTV廣告
- Facebook 2015-2018
Software Engineer

## 為什麼大部分的技術領導者似乎都差強人意？
> Tead Lead 最終只是個IC - individual contributor

### 原因一：自私不是病，自私起來要人命（更無法取得民心）

- 被自己的固有思維局限住，往上爬之後不在是競爭繼續往上爬，而是放權來帶領下面的團隊。
- 不願意放權.

### 原因二: 凡事事必躬親, 只會累死自己.

- 喜歡攬事情，把自己累死但是團隊的產出真的沒有比較多，下面的人也沒有學到精髓。
- 他人或許很好，但對於團隊效率來講 cp 值不是很高（一個人的時間還是有限）

## 所以, 什麼樣才是一個好的 Tech Lead 呢?

### Tech x Leadership 乘法者角色的戰略家
> 推薦 Andrew Grove 的書 (intel CEO)
- 深厚的技術底蘊
- 將技術視野與商業目標對齊
- 將一個人的能力倍數放大至整個團隊

### Technology（技術實力）是你最重要的超能力

- 不管你是前端/後端/mobile 你深厚的技術背景與Exp就是你最重要的武器, 不管在做什麼任務, 千萬不要忘了繼續磨亮這把劍.
- 對你技術上的尊重，會成為你帶領其他成員最重要的隱形幫手
要持續成為在你的技術領域最有知識深度的人

tech lead不是真正發薪水的人，不能因為權讓別人讓你服從，你要在你的領域上面成為最有知識深度的那個人。

#### Key#1 : Go Deep, Not broad

- Teach Lead 不是該什麼都懂一點嗎? yes and no
- 對於一個領域的知識深度理解，仍然是成敗的關鍵，尤其是AI時代
深度理解知道背後運作的原理，才有機會在 worse-case 解決問題
比如資安,
- 危急狀況發生的時候，只有垂直領域的專家可以出來拯救大家
- 如果身為 tech lead 的你永遠救不了火，就難得到大的尊重。
- Be to go to person

在 vibe coding、AI 氾濫的年代，只有知道最後深層原理的時候才有辦法找到worst case的解決方法。

深度理解知道背後運作的原理才, 才有機會在worst-case 解決問題. e.g. vibe coding

對於一個領域知識的深度理解, 仍然是成敗的關鍵。

#### Real life example : IG Story Ads video glitch (小故障)

facebook & IG , code base 是分開的.
不是IG的問題, 是 FB 的 infra 問題. 研究FB的code

the reason of 提這個 example? 我就成為了 video infra 的代理人.
不知不知覺就成為一個橋樑

Be the 'go-to-person'
要被別人把名字寫在捷徑裡.
你在某些地方會被記得, e.g. promotion meeting
你也可以想想看, 在什麼時候/什麼地方你會被別人"想到"

#### Key#2 : Think High-Level, Plan Long-Term

- 看到big picture，不要見樹不見林
- 如何有效的**分配資源**是 Tech Lead 的關鍵任務
- 同樣的 feature request 實作方式取決於目標
-

**當 PM 有問題要討論，先問他 WHY**
- Focus on WHY
> 我們常常當工程師的時候，會先去專注在怎樣把東西做出來，把東西做得複雜做得很難，好像工程的狀況就會很厲害。

但當你變成一個startup的管理者，就不得不去想資源分配

任何資源浪費都會跟公司存亡有很大的關係。

要去逼他去想, 為什麼要做這件事, 好好想清楚.

同樣的 feature request , 實作方式取決於目標.

##### Bonus: 多和你的上下游組別聊天（前端&後端）

身為 Tech lead 知道上下游的team(前端/後端/DB) , 這一年/半年準備做什麼
e.g.跑去前端 meeting 去了解他們的設計理念. 後端做的更好/更順.
前提是你平常已經很熟了.

#### Key#3: Be the Code Guardian

- Codebase 的品質就代表了你這個人與你的團隊的品質（知道一個團隊最快就是看 code，像是 PM 很難從 spec 就看出來）

隔壁組的人或是主管，不太知道你的技術實力，畢竟都要花時間要去理解的，但誰都可以看到你的code
Tech Lead 50% 時間花在code review 是合理的.

**把關程式碼三關鍵**

1. <div style="color:purple;">Code Review! Code Review! Code Review!</div>

##### Cloudflare incident

為什麼講這個例子： 如果有做到更好的把關，相信這件事情可以提早被抓到

小Tip: 專案"初期"的PR 優先審查.
像蓋房子一樣, 先看基底囉.

2. Set up Coding Guidelines
- 這個 codebase 的取名規則是什麼
- 多大多小的功能需要自己切一個function ?
- 整個repo的資料夾要怎麼分類?

> 有彈性不一定是好事，合作上面就會變得超級複雜

3. 勇敢的做 Refactor
- 注重系統的 hotspots 很常改，改了很痛苦，很容易有 bug 的核心模組
- 推動 Refactoring: Focus on Business Impact
> 透過一些速率，或是 bug 的角度上面去跟上面解釋，讓 business端的人也能知道好處，更進一步同意你的訴求ㄉ
> [name=DanSnow] 白話： 把這個改動跟成本連結

你這個人就代表你的團隊的品質

### Leadership

#### 你的成敗取決與團隊的成果

目標： 確保團隊的節奏是 in sync 的
（像是交響樂團的指揮）
你沒有在表演, 但你要確保團隊的狀況是OK的.

#### Key#1: Communication is everything

- 具備同理心的主動聆聽 (Active Listening) 建立心理安全感。
- 你不需要當那個總是對的人, 你需要當那個大家願意對你說真話的人, 否則只會得到'其實不認同的yes'
> 你需要聽到那個實話. 知道真正發生的事情, 你才有辦法解決底層的問題.
> 如果假裝的yes 只會做歪, not in sync.

- 急於給出解方只能解決表面問題 Root casue 才是改變的關鍵。
- e.g. 不是不能 meet deadline，而是不理解 why
- Always over communicate：確保自己的想法對方有確切的接收到。
- TCP : 所有討論後都要有書面記錄佐證.
- UDP : 不斷重覆.

溝通是唯一知道每個人的想法

> 不用太急著給出解方，雖然你很急於要幫助他的樣子，但這件事情就會這樣過去，你也沒辦法解決到任何問題。
> rootcause 才是改變的關鍵
> 會不會不會估時？到底是什麼原因？主動去理解。
> 雖然花很多很多時間, 但還是無法meet deadline, 1 on 1 後來才發現他其實他沒有 buy in
>

當工程師沒有辦法真正的理解這些東西，就沒有動力去做開發，後來有調整一兩天的時間讓pm可以跟他溝通，讓 enginner 可以更快的理解東西要做的，他有貢獻他的想法，這個東西他有參與討論他就更有動機把這個東西處理完。

> [name=DanSnow] 我以前的老闆：溝通不是說話，是讓對方聽懂

人是非常容易健忘的，只有一直重複說，才有機會讓他真的知道什麼東西是真的很重要，然後他有記得這件事情

#### Key#2: 信任領導 Trust Leadership

- 信任領導是基於信任為最核心的關鍵的領導風格，風事以信任為出發點來做 leader 與團隊成員之間大大小小的決定，default 的選擇就是信任
- 實務面的好處: 不需要有額外的'確認'步驟.
- 情感面的好處：信任是一個巨大的 motivator，能產生被賦予重大的使命感
- （要很大的信任感去支撐）表現越好的成員越加分！

- 信任的秘密：信任是一種交換條件，最特別的是它是不可逆的資源，一旦被打破過，就算再怎麼修復，都無法回到 100% 狀態。
所以'不能打破信任'必須是雙方最大的共識

[My life as a CTO — 信任領導
](https://medium.com/@jocelin/my-life-as-a-cto-%E4%BF%A1%E4%BB%BB%E9%A0%98%E5%B0%8E-dc385389b911)

#### Key#3: Feedback is a Gift. (Facebook 的)
- 收禮物（永遠心存感激）
- 自我成長的最好方法
不論收到好壞 feedback，都是珍貴的禮物。
- 收到當下一定會有情緒, 要等情緒過了才會感受到 feedback 的力量.
> 爬蟲腦
> 不論是好的不好的都要心存感激，但收到評論就是會有情緒，但情緒過了之後你就會理解到 feedback 的力量，雖然錯誤當下你不一定會好好的理性思考

- 送禮物 （給予 feedback 的藝術）
- 公開褒獎稱讚，私下給建議，不要公開場合給建議
- 對事不對人
- 結尾要收在明確的行動目標

> 人都要面子，若他覺得面子掛不住的時候，他什麼東西都聽不進去。
> 若你溝通都攻擊別人怎樣不好，這樣其實也沒什麼意義。
> 你若打斷同事說的話，他沒辦法講完他要講完的事情，讓他知道到底發生什麼狀況。

coomunication is everything
溝通溝通再溝通
trust leadership
信任領導
feedback is a gift
回饋是種禮物

<div style="font-size:42px;">Trust Yourself </div>

fake it until you make it

---
( ੭ ̇ᗜ ̇ )੭ 聊天室 ( ੭ ̇ᗜ ̇ )੭
A2 跟這場都好想聽～～怎麼辦
>我也是，無法決擇耶 Q_Q
>最後決定聽 A2 了，跪求聽這邊的大大們的共筆 ( ੭ ̇ᗜ ̇ )੭
>我也無法抉擇
我在這
（:point_up_2:這個發言感覺好帥）

深耕怎麼偷懶的我
>不會偷懶的工程師不是好工程師 （被打

對於一個領域知識的深入了解，這裡是指產業的知識還是技術上呀🙏
>都算吧 主題也說技術領導 但是概念應該通用ＸＤ
>謝謝你🙂

tell me why!!!
試著把事情做的簡單也很難ＸＤ

這場筆記要寫的很快，東西好多

好奇: code都公開, 但跑去看其他團隊的code 這件事情是否其實很少發生?
除非出包?
>好像還沒有去看過其他團隊的code
>>只要有空擋餘裕都會看吧？

昨天有別的 team 的人，突然跑來問我放在公司內版控私人的專案
>所以是把自己專案放公司版控？還是幫同事做版控ＸＤ
>???????認真
>工具類的專案或文件？
>> 我會寫些自己用的小工具，是個 jira 的 mcp ，加入了我們 team 的邏輯客製的版本，放在上面是為了分享給其它的 team member 用，現在 vibe coding 很快
>>> 了解 現在應該可以用plugin的方式安裝？
>>>> 不確定你說的 plugin 是指什麼
>>>>> 想說看claude code可以把自己的設定打包成pluging給其他人用而已ＸＤ
>>>>>> 了解，會寫成 mcp 是因為我們 jira 要填的欄位很多，但大部份的填法是固定的，寫成 mcp 比較方便

Code Guidelines
>ai 時代就叫ＡＩ改ＸＤ
> 同意, 放在rule就好了 ?

昨天這一場「從設計到共識：悠識如何在每一次新專案裡，用溝通建立信任關係」也有提到建立心理安全感的議題，那一場的共筆也是很詳盡
>真的 男生講者講話讓人覺得很安心

default 信任 OK , 之後也是要看對方靠不靠譜..吧?

卡最後一行別人會打不了字啦ＸＤＤ
Sorry!

never mind

前面講 推薦 Andrew Grove 的書 是哪本啊
> 好像就是下面我推的那本

個人推薦書單 by DanSnow
- 葛洛夫給經理人的第一課
老實說我自己也是被推著上 lead 的人，感覺也可以稍微分享點故事

這場不知道有沒有簡報
>感覺這場好精采，希望講者可以分享簡報
>> 講者有在 theards 中貼文~ 可以去領

哇噻，隔壁過來看這場是集合整個活動的筆記手在打嗎？ XDDDD

2025.12.15 更新：我昨天有在 Threads 留言了，目前還沒收到簡報 QQ
2025.12.25 更新：收到講者的簡報，太開心了