Leading Snowflakes — 閱讀筆記
“Leading Snowflakes The Engineering Manager Handbook” — Oren Ellenbogen
管理職，初來乍到，一切都很迷茫；對於管理的知識只有彙整之前的工作經驗、觀察或與其他同事閒聊時獲得，知道主管做了什麼事底下的人是正面的、什麼事是負面的；也就大概只有這些經驗想法，知識是破碎的，沒有一個有系統理念，於是我開始看書，開始記錄一下每個作者的經驗；如果遇到相同的事物，有了「知識底氣」之後就不會在手忙腳亂了。
Leading Snowflakes
作者在過去近 20 年的工作經歷中，從原本的軟體工程師一步步踏入管理職；擔任過不管是大公司或新創公司之 Technical Lead、Engineering Manager；本書詳細點出從工程師踏入管理職時會遇到的瓶頸及該用什麼方法整理、解決。
我覺得與我的背景非常相似，都是本來做軟體開發，初探管理職；藉由書中提到的重點讓我學到很多可以怎麼做的方法！
- 本文僅為個人筆記夾雜些許個人觀點，在這資訊碎片化的年代，強烈建議要自行閱讀過原文書，才能有系統的吸收精髓。
- 筆記的意義是之後回頭來看，比較容易快速定位到想複習的點。
- 部分內容直接摘錄原文。
Lesson 1. — Switch between “Manager” and “Maker” modes
從工程師(Maker)到管理者(Manager)的過渡。
完成好任務甚至優雅地解決難題是優秀的工程師的衡量標準，但做為管理者以不是用完成任務的能力來衡量，這部分我們已經證明過了，而是以帶領、推動、提升能力的團隊目標作為評斷標準。
但也不能完全將自己從任務中抽離，完全與任務細節抽量導致與團隊成員斷開連結，對於執行成果、優先權、信任方面長期來看會有很大的風險。
所以不是說當管理者就不用做工程師的事，而是兩邊都要碰，需要的就在 工程師(Maker) 跟 管理者(Manager) 之中取得平衡。
做為工程師時我們喜歡有連續不被打斷的時間讓我們保持在 Context 中去解決困難的問題；但做為管理者時，我們需要的是時常跳出來幫助團隊、關心隊友，所以被打斷其實是管理者的工作之一。
但我們同時需要身兼工程師和管理者，那該如何是好？
作者建議建立兩個 Calendar ，一個是 as Maker (工程師)、一個是 as Manager (管理者)，然後每日一大早給自己 15 – 30 分鐘整理思緒，安排本日行事曆，該做什麼事、有什麼會、有哪些空檔的連續時間點可以拿來解決任務(as Maker)。
作者的行事曆範本
我們也需要專心的時間
作者所述，現在身為管理者，但我們仍需同時處理任務；可利用的空檔專注時間對我們來說比以前更重要。
作者提到，可以在需要專心的時間透過一些動作傳達給隊友，暫時不要打擾我！
方法有：到會議室、戴上耳機、或甚至買一個 ON AIR ! 的開關燈放桌上。
如果不是緊急問題，可以先請隊友留言或彙整資訊寄信給你，等到專心時間結束後再來處理。
評估自己做為工程師的時間能解決的任務
因為已經不像以前純當工程師(Maker)的時候可以全心全力灌注在開發需求上，所以要依照工程師行事曆所能運用的時間來選擇能親自執行的任務。
不要成為團隊的技術瓶頸，我們的任務是提升團隊能力、探索新技術、提升公司對外或隊內的技術視野；可做的事有預先研究技術問題，然後與隊友分享並交由隊友執行、解決公司技術債、流程問題增加開發效率、使用新技術、將公司技術開源、開放 API、對外黑客松…等等。
最重要的還是平衡
作者建議可以從 15–20% 比例開始調配，本來是 100% as Maker，現在可能是 20% as Maker / 80% as Manager（但這要看實際團隊大小及成員能力，作者也說 50% / 50% 也有可能），就是不能在是 100% 投入工程開發，要多花心力在管理上。
善用 1:1
定期與隊友 1:1，互相 Feedback 並分享所學到的東西。
如果管理者的任務吃掉你所有時間
作者最後提到，如果你管理的任務太多完全無法做工程 (as Maker)的事，與任務、技術脫節時，可以考慮每週選幾天 WFH 與公司隔離或參加黑客松。
Lesson 2. — Code Review” Your Management Decisions
定期 Review 你身為管理者下的決策。
身為工程師時我們有很多方法或工具，只要遵循就能提升好能力，諸如 pair programming、code review、design pattern；但做為管理者，尤其菜鳥我們感到相當孤獨。
我們不想承認對上或對下一無所知、害怕為團隊成功負責也擔心沒拿捏好技術(債)與商業需求之間的平衡。
作者提到要跨出去尋找提升管理能力的，公開徵求 Feedback & 提高管理技能的方法；做管理者時也能像做工程師時的熱情。
記錄＆回頭審查決定
同事與老闆都是我們很常低估的強大資源，我們可以快速的從同事與老闆的 Feedback 中學習；建立好紀錄＆回頭審查決定的習慣，可以讓我們更好的得到 Feedback。
作者提到：
「There is no one right way, there are only tradeoffs.」
我想也是，如果不是進退兩難的問題應該也不會問你；如果問你就代表隊友不知道該如何決定。
我們可以列出選項並提供決定給隊友，但與此同時也要記下所做的決定。
作者提供的紀錄 Sheet 範本
養成紀錄的習慣，並且要確保內容是之後能回憶的。
作者建議，每個月回頭審查，可以與老闆或其他管理者或其他同事分享討論決策（至少要分享一半的問題），聽聽別人的看法；可以匿名保護當事者，對事不對人，並記錄下來。
回頭審查時的要點
關於問題：
- 引起多少技術問題？
- 是個人問題？
- 只是某個成員的獨立問題？（是不是單純只是他不了解目標？）
- 這問題在其他團隊或會重複出現嗎？
關於決策：
- 這問題真的需要管理者來決定嗎
- 有沒有問過隊友的建議
- 有沒有其他比較有經驗的人能提供建議
- 現在重新思考，還會是同個決定嗎？
Lesson 3. — Confront and challenge your teammates
推動隊友跳脫舒適圈以及不讓自己變成混蛋跟陷入陷阱。
作者提到一開始很不習慣，因為本來是朋友的同事現在變成部署；他害怕會傷害本來的關係；所以一昧地承擔所有收尾的事，但最後他發現他越是保護越與隊友距離越遠，因為他一而再的埋頭苦幹，少了分享讓隊友失去信念。
回頭來看，作者說與其害怕傷害隊友的感覺不如說出內心真實所想的，「害怕傷害隊友」這單純是自己自私的想像，沒有必要；而且這是身為管理者的責任，帶領團隊成長前進；要遠觀大局、控制風險。
分享真實想法對雙方都很難，但這是身為管理者的責任。
我們要展現同理心而不是同情心，為了讓他們的工作真正出類拔萃，他們需要我們客觀的意見。
作者提供以下三個要項讓我們能在情緒與行爲中做出平衡：
- 我有展現出同理心嗎？
- 我有清楚說明我的期待嗎？
- 我有以身作則嗎？
「If you want to achieve anything in this world, you have to get used to the idea that not everyone will like you.」
如果你想要有所成就，就必須習慣不會每個人都喜歡你的想法
四個常見的陷阱：
- 相較於掩蓋，我有公開分享失敗經驗嗎？（可以是寫文章、寄信給所有人）
- 忘記統整討論結果（要習慣紀錄 1:1、討論的結果）
- 使用錯誤的 Feedback 媒介，沒得到真正的問題（依照團隊文化找到適合的 Feedback 渠道，EX: 1:1）
- 不即時的 Feedback 我們需要注意，工程師喜歡挑戰自我、提升技能，同時也想要獲得尊重、主管的 Feedback；我們的任務就是帶領團隊成長，所以在每次有 Feedback 機會時不應該拖延，因為不做決定也等同於做決定；而且一旦 Feedback 的風氣衰弱之後要再點燃就更困難。
Summary
可以花時間寫下激勵隊友的方法及詢問主管是否太保護隊友？
Lesson 4. — Teach how to get things done
如何以風險較低的方式完成任務。
以身作則是不錯的方法，時不時參與團隊的開發示範如何計畫、產出好的功能展現我們想傳達的理念；另外要注意，在這其中要多説 Why? (為何這樣做)、少說 How? (該怎麼做)
作者提到極度透明的文化，讓團隊成員有完整的 Context 能提高推動決策的能力。
降低風險
- 為了降低產出的風險，作者建議將需求拆成許多小塊迭代功能；並將此想法與其他 Team 溝通分享。
- Scale and performance — always have a backup plan 這功能會不會影響效能(或造成其他問題)？可以提前知道嗎？有沒有備案(開關)；在沒有備案之前寧可不要實作，因為會影響團隊信心。
- 將任務拆解成小任務，降低 Deadline 風險 一開始可能很難，但可以訓練學習
- 善用同儕壓力 將任務拆給隊友共同協作，彼此共同努力(Code Review 亦也是)
- 持續對內及對外溝通 對內：確保期望、同步、Deadline、資源，對外：溝通、如果時間很趕了可推掉不重要會議
- 支援、修 Bug、文件 不是釋出功能就好，還要做好客服支援、修 Bug、還有文件
- 做好回顧及委派任務，提供其他人領導機會
- 挑選幾個能以身作則的 Task
- 詢問隊友學到的東西、能讓他更積極的動機、討厭的事
Lesson 5. — Delegate tasks without losing quality or visibility
委派任務的同時又不喪失品質跟能見度。
身為管理者必須做好任務委派，作者認為委派就該設定好期待並相信被指派的隊友有能力執行並是有機會學到東西及保有發生錯誤的空間，管理者另一方面也要保護隊友來自公司的壓力。
作者使用以下表格進行記錄：
這邊主要紀錄的是對團隊目標重要的任務，日常工作不用紀錄。
- Must 寫下任務內容
對於是否要將任務委派給隊友，作者會先問這個任務是否真的只有我能做且是屬於管理者該做的事，第二個是這個任務是否是長遠的領導任務；如果都不是則委派隊友執行。
對於要委派的任務可評估隊友的經驗、技能，找到合適的人選。
- External 關於外部或上面期待的資源 (Feedback/Tool)
- Delegate
Delegate 的部分，我們可以提供一頁的 Paper 闡述我們的期待、簡單的範例。
Lesson 6. — Build trust with other teams in the organization
團隊與團隊兼協作的默契。
作者闡述，組織為了能做更多事會拆分很多小組進行快速決策處理；對於各小組的方向定義其實不難(EX: iOS 就是做 iOS App)，難的是要對齊所有小組的目標。
小組越多就很難統一所有人的價值觀、期望、優先權、隱含的期望。
應該要關注拆分小組的理由跟動機而非產出，否則可能導致矛盾。
作者認為要對齊各小組的方向有以下方法：
- 團隊要有願景，而不是只把任務處理好
- 管理者需要區分出需要與想要
- 優化團隊更快的完成正確的事而不是完成更多的事
- 與其他團隊經理建立良好的溝通 作者建議可以在每兩週的管理者會議分享團隊內的狀態、分享自己團隊阻礙與痛苦、接下來會做的主要任務、做的原因
- 與其他團隊對於優先權意見不同時，可解釋引出其他因素（EX: 這個做了之後，可以降低 CS 客訴、一勞永逸、加乘效果…）
- 先了解外部團隊需要我們幫忙的地方並且主動密切追蹤
- 再來提出我們團隊需要外部團隊幫忙的點
- 列好需要確認的清單，確保在會議上有討論到；如果沒有可以在會後拉相關的經理討論看有沒有其他可能
- 若不可能則要權衡可能會延遲時間或替代方案，並要讓關係人知道（防止在背後指指點點）
- 一切都是權衡
另外還有 5 個讓隊友能與其他團隊建立密切關係的方法：
- 簡單的感謝信（感謝協助）
- 交換團隊工作
- 內部技術年會，互相分享
- 一起觀察使用者使用狀況，一起腦力激盪提出優化方向
- 邀請一位其他 Team 的隊友加入我們的工作
Summary
「 imagine that someone from Team A drops a feature that Team B needs, due to an urgent support issue. Without communicating this priority change to Team B, trust will be decreased even if it’s a justified priority change.」
「 difference between transactional trust and relational/emotional trust 」
- 了解交易信任與關係信任。
- 交易信任 — — 人們是否會履行承諾並完成任務
- 關係信任 — — 人們是否以建立和保護關係的方式行事
Lesson 7. — Optimize for business learning
建立商業學習文化而不是建造文化、優化吞吐量、優化的價值。
- 過早的優化是災難
- 優化當前問題為重，不要為了優化而優化
- 即使不是整個專案的負責人，我們仍可就內部運作進行優化，大的成功多半來自小部分的優化累積
- 身為管理者我們必須展現決策背後的動機
- 建立商業學習(價值)文化大與建造文化（重點不是建造解法，而是我們試圖解決的商業問題）
- 優化效率 vs 優化吞吐量問題： 優化效率：解決單一 task 的時間 優化吞吐量：一個時間範圍內(EX: 一季) 能解決多少 task
- 知道每個優化的 Impact，
- 自動化的重要（能一勞永逸節省時間）
使用 AARRR 原則為價值優化：
- Acquisition：如何引入更多使用者
- Activation：如何引導使用者完成讓他了解產品價值的任務（EX: 鬧鐘 App，新手引導他完成設立一個鬧鐘）
- Retention：提升回訪率，回來使用次數
- Referrer：讓你的使用者、內容，帶來更多流量
- Revenue：數字化評估使用者帶來的收入
這五項息息相關，如果因為 Retention 低，可能可以同步調整 Referrer、Acquisition。
身為工程管理者，我們要做的不是埋頭寫 Code 或是全心投入在技術；時不時應該要重新對齊產品價值。
當產品還在草創初試市場狀態時，應該要以優化效率(快速解決任務釋出)為主，重複著以下流程：
功能能提升 Retention -> 釋出功能 -> 學習 -> 調整＆重複。
評估功能到釋出每個階段可以優化的地方（花太多時間在設計？在討論？）
可以投資 20% 時間減少 80% 的開發時間嗎？尤其是令人痛苦的點
可以先實驗或發布給最小受眾嗎？避免功能很大包結果最後沒人用。
- 要做好數據追蹤，才能了解努力的成效
「If you can’t make engineering decisions based on data, then make engineering decisions that result in data.”」
雖然相較「這功能不做，公司會倒閉」跟「這功能會導致技術債」，前者當然更可怕；對於技術債，作為管理者如果能爭取更多時間解決我們應該就要做到，我們應該要做好溝通及控管。
優化可能不會用到的程式意義不大。
- 過了草創試驗期，產品模式趨於穩定；這時候比較適合優化的是吞吐量(EX: 給定 X 資源，得到 Y 產出)
- 給予商業需求可預測性(同上)
追蹤團隊產出 (EX: 「01/01/2013–14/01/2013: 2 Large features, 5 Medium features, 4 Small )，經過長期統計；可以藉此提供預測。
找出＆解決瓶頸：
- 同步的溝通：例如產品開發流程，需要設計資源；在進到工程開發階段，我們是否已經有明確的規格可執行開發？還是在等待？還是有什麼我們可以先做的？
- 基礎設施：讓程式碼好擴充、好維護
- 自動化：使用自動化處理繁瑣的人工操作，節省時間之餘也能避免出錯
因為商業策略隨時在改變，我們應該對於優化策略保有更開放彈性的想法，優化的總結還是以商業需求為主。
Lesson 8. — Use Inbound Recruiting to attract better talent
關於招募。
平時就要開始做以下事項，防止突然缺人才要開始，那只能回到傳統找人方式，不停的面試但卻很難找到合適的人。
對內：
- 培養良好的工程文化環境 (EX: Code Review、年會…)
- 打造吸引人的工作環境
- 像經營品牌一樣
- 團隊成員共同努力
- 加強人與人的連結（EX: 慶生）
- 先讓成員是對團隊感到驕傲的
對外：
- 內部團隊每週定時對外回答社群問題 (EX: Stackoverflow. . )，加強曝光
- 在程式中隱藏招募彩蛋(EX: 網頁開發者工具)
- 與社群分享我們團隊遇到的問題及解決方法（文章 or Talk）
- 舉辦黑客松
- 建立 Side Project (EX: 開源專案)
分配以上各任務給團隊成員，大家一起為找到好人才貢獻一份心力。
Lesson 9. — Build a scalable team
打造可擴充的團隊。
建立可擴充程式以是我們之前擔任工程是該有的職責，但現在要挑戰的是打造可擴充團隊。
不像程式，人有期待、需要、夢想要顧及。
作者想要打要一個快樂的工作環境、隊友之間了解任務的期待、新挑戰；而且要能持續保持這份熱情。
- 對齊目標 對齊個人願景與公司目標，如果不了解當前公司的目標很可能造成團隊功能失調。
- 對齊核心價值 算是共識及默契，對於做事方式、什麼重要的默契；團隊核心價值也不是一成不變，要與時俱進。
- 平衡 對於團成員的職能、成長，分配不同的願景、自主權、擁有全；互相協作一起成長(EX: 新人只期待能了解公司做事流程，老鳥要 Code Review、指導)；每個人都應該要有成長性。
- 團體的核心價值觀大於個體 可能導致有人離職，也需要時間耐心才可能實現；也有許多挑戰 (EX: 有人離職時會質疑核心價值)
- 成就感 成果要能有成就感，做為管理者不能讓隊友干燒熱情
實踐
1. 定義團隊願景 EX: 作者的團隊是做爬蟲的，他的團隊願景就是「To build the largest, most informative profile-database in the world.」 請注意是願景，不是短期目標也不想做的事。
2. 定義團隊核心價值 在挑選核心價值時可以「這個價值重要到會因為沒有而開除某人嗎？」 寫下核心價值、原因。 作者提供以下幾個他寫的核心價值： - 不要讓別人(其他團隊)來收拾善後，自己(團隊)的錯誤自己要承擔 - 對團隊所有成員保持忠誠尊重 有了核心價值在招募或開除更有評斷準則，還有更能有做事的基準。
定義成員對團隊對管理者的期待
- 提供具有生產力且開心的工作環境
- 知道 Task 的 Why 而不是 How
- 能夠得到真實的 Feedback
- 有機會帶領其他成員
- 能夠分享工作成果
定義對團隊成員的期待
基本期待：
- 完成任務
- 保持學習熱忱
- 保持分享、教學熱忱
- 知道做事的底線 sense
個人期待：
- 依照能力設定期待
- 有能力訓練他人改變
- 推動改變而不是抱怨
我們是團隊，團隊成員有自己的責任跟要交付的成果，同時也要與其他人協作，幫助他人，互相成長；定義期待像是種契約，在原本的同事關係變成管理者關係之下，能更好更有目的的領導；定義這些項目不容易，需要時間、耐心去迭代。
「You can’t empower people by approving their actions. You empower by designing the need for your approval out of the system.」
有任何問題及指教歡迎 與我聯絡 。
===
本文首次發表於 Medium ➡️ 前往查看
