Engineering Ladders
技術階梯
之前身為EM的時候(Engineering Manager)很喜歡在1對1會議上問團隊成員一個問題：把能力分成幾個象限，你會各給自己幾分？你預期要達到幾分？
這套流程我很喜歡，能夠有效在1對1會議上開啟一個有用的對話，並且也能同步彼此的認知以及安排未來的職涯發展和工作規劃。
事實上，這樣的作法並不是我獨創的，也有很多制式的模版，在Github上甚至也有人開源一個工程端的泛用型的模版。
這篇文章是對這個模版的翻譯。
在上一篇文章我們提到主任工程師的四種角色，在這篇文章中我們對工程端的常見四個角色定義其能力象限。
- Developer：另外常見的稱呼有programmer或軟體工程師，這角色需要有很深的技術底子。
- Tech Lead：這就上一篇文章提過的角色，算是系統的擁有者之一，需要兼顧實際開發、架構知識以及線上環境維運。
- Technical Program Manager：TPM是驅動跨工程團隊協做的先鋒，為的是讓產品走向不至於與技術脫節。
- Engineering Manager：部門的管理者，負責讓部門維持和諧氣氛以及提昇部門的技術水準。
在文章中還有更多對於每個角色的仔細描述和比較，但因為不是模版重點，所以有興趣的可以自己查閱。
象限解釋
- 技術(Technology)：技術堆疊和工具的知識
- 系統(System)：對於系統的了解程度
- 人際(People)：和各功能團隊的關係
- 流程(Process)：開發流程的參與程度
- 影響力(Influence)：對於組織的影響力
影響力這個象限比較特別，與其他幾個象限是正交的。其他幾個象限彼此之間有可能互相影響，例如技術深度越高，那麼對於系統的了解就會越多，當然開發流程的參與程度也會提高。
但影響力並不單單是受這些象限影響，還多了更多主觀/客觀條件。
在模版上，每個象限都有分級，上位階級的條件是完全涵蓋下位階級，所以若是僅有某部分達成上位條件，也不能當做上位。
等級解釋
以下會就每個象限的等級提出具體解釋。
技術
| 等級 | 描述 |
|---|---|
| Adopts | 主動學習和接納團隊內的技術和工具 |
| Specializes | 已經可以實際上手一個或數個開發工作，並且持續學習不熟悉的領域 |
| Evangelizes | 做研究、做PoC，已經可以為團隊導入新的技術 |
| Masters | 對於「整個系統」的技術堆疊有很深的了解 |
| Creates | 可以設計、創造新的技術，並且廣泛被無論內部或外部團隊使用 |
系統
| 等級 | 描述 |
|---|---|
| Enhances | 成功推送新功能或解bug |
| Designs | 設計和實作中大型的功能同時也解決系統的技術債 |
| Owns | 線上系統的維運以監控，並且確保SLA |
| Evolves | 演化系統來支援未來的需求以及定義SLA |
| Leads | 領導系統走向完美，並在發生災難時制定修復計畫 |
人際
| 等級 | 描述 |
|---|---|
| Learns | 快速從他人身上學並跟上腳步 |
| Supports | 主動支援其他團隊成員並幫助他們成功 |
| Mentors | 教導他人使其快速成長並鼓勵其參與事務 |
| Coordinates | 與團隊成員協作，能有效提出反饋以及有用的討論 |
| Manages | 管理團隊成員的職涯、績效以及氣氛 |
流程
| 等級 | 描述 |
|---|---|
| Follows | 跟著團隊流程並持續做出功能 |
| Enforces | 推行團隊流程，確保每個人都了解流程的優缺點 |
| Challenges | 對團隊流程提出質疑，找尋更好的解決方案 |
| Adjusts | 調整團隊流程，蒐集反饋並引導新流程落地 |
| Defines | 能根據團隊水準制定正確的流程，兼顧敏捷與規範 |
影響力
| 等級 | 描述 |
|---|---|
| Subsystem | 在一個或多個子系統上有所貢獻 |
| Team | 對整個團隊有貢獻，而不僅是一小部分 |
| Multiple Teams | 不僅在所屬團隊有貢獻，也對其餘團隊有貢獻 |
| Company | 對整個技術部門有貢獻 |
| Community | 對技術社群有貢獻 |
後話
其實我覺得他描述的影響力有點太過了，我們又不是要做地球超人，最後一項應該推廣到整間公司就夠了。