編者按：初創企業在早期一般都是人人身兼數職，倡導扁平化的管理，並不怎麼看重頭銜。但是隨著組織的擴大，初期的這種管理模式會引起諸多問題。身兼軟體工程師、經理與創始人角色的Chuck Groom從個人經驗出發，分析了設定工作階梯的好處，並提出了他的建議。無論是創業公司管理人員還是軟體工程師都可以參考一下。
軟體公司應該審慎地考慮工程崗位職級的設定，制定好一個工作階梯，向員工解釋清楚對其的希望，不同角色之間的區別，以及職業發展的領域。
在本文中，我將討論為什麼制定工作階梯可以幫助到每個人；好的工作階梯應該是什麼樣的；我對軟體工程師職級是如何思考的；最後我還會提供一些建議。儘管本文的受眾是管理層，但工程師看了之後也應該能從公司的角度去思考而獲得一些洞察。
注意，本文僅討論獨立貢獻者（IC）的工程發展路徑。其他並行的發展路徑（管理、產品）包括轉崗均不在本文討論之列。這些話題都值得討論，但不在本文範疇之內。
是的，工作“階梯”的想法有點奇怪
工作“階梯”這種說法暗示了所處行業的高度結構化、非常穩定的，有著抵達某個有意義的終點的長期路徑，就像成為合作伙伴那樣。但是現代的職業流動性更強發展方向更加多樣。員工往往每幾年就要變動一下工作。
不要把職業階梯看成是長遠的人生規劃。這樣你會把太多關注放在階梯頂部（“我究竟應該怎麼過我的一生？”），但這是你下一步的關注重點。階梯就是個工具，讓你設定好對未來幾年的期望。
假設你沒有工作階梯
新公司或者團隊往往對頭銜或者角色沒有很好的定義。實際上，這他們也許反而會引以為豪；你應該聽說過“我們是一家扁平化的組織”，“頭銜並不重要。”儘管大家的薪水可能很不一樣，但大家普遍感覺這是英才管理的模式。
好吧，如果沒有工作階梯地球也照轉的話，為什麼要自找麻煩改變這些呢？我們可以看一些例子。
Frank希望晉升到“資深”頭銜，但是我們感覺他還沒準備好；但是他反問為什麼不行→ 我們得想辦法解釋不同職級之間的差別，並且指導Frank應該發展那些技能。
我們在面試一位候選人。大家都比較中意她，但在招聘彙報時我們對提供2級還是3級的角色意見產生了分歧→沒有清晰定義的招聘門檻，重要決策就變得太過主觀了。
我們的初創企業沒有正規的頭銜。我們剛剛融了A輪，並且還一併引入了新的領導層。經過緊張的閉門磋商之後，他們給每個人都分配了職級，但是很多工程師非常惱火自己只是“初級。”→哦廢話，頭銜不重要直到它們變得重要。現在一堆人惱火失望了。
幾年前我們以85000美元的年薪招聘了Karen。今年夏天我們又僱了Noreen——在跟Facebook搶過一輪之後，他的薪水被提高到了120000美元//年。Karen和Noreen做一樣的事情。一次喝酒之後，Karen發現Noreen的工資居然比他高這麼多。→這是個災難。每個人12萬美元我們可支付不起。但Karen完全有理由宣判這是犯規。
當設定好職級時每個人都是勝利者
工作階梯對員工和公司都有幫助。
管理
：好的經理應該對員工表現是否滿足當前職責要求，以及需要發展哪些職業技能給予定期反饋。工作階梯提供了一個不帶偏見的框架來框定這些討論。
招聘
：好的工作階梯應該能夠很容易地幫助設定對應聘人員的技能集要求。團隊可以針對每一級建立一套標準的問題集和招聘門檻，並且對員工之間進行同類比較。
HR薪酬範圍
：只要招聘員工就得確定薪水問題。這就需要確定內部層級以及將這些層級與業界市場費率匹配的手段。
公司原則
工作階梯傳達的是那些技能和特質重要。這些必須與公司的使命與價值觀一致——你希望大家把解決問題的文化聚焦到最終客戶、解決衝突以及做出艱難決定上。出現在公司原則和使命的語句應該納入到工作階梯裡面，也應該用到員工反饋裡面。Amazon的領導力原則就是很好的例子。
好的工作階梯應該包括哪些要素？
制訂得當的工作階梯應該做到：
解釋不同職級的差別並證明其合理性
。每一個職級應該是儘可能不同的角色，而不僅僅是不同的技能程度；你需要的是階梯函式而不是漸變函式。
告訴員工那些因素影響到晉升（以及自我改進）
。工作階梯是職業發展計劃的記錄，同時也應該能夠解釋用於員工評估的條件是什麼。
應該容易理解和閱讀
。少即是多。這應該是結構清晰語句精煉的參考指南。
反模式包括：
角色跟我們所做的事情並不匹配
。職級和價值觀的描述跟我們日常經歷和需求並不一致。
技能和表現列表很長
。員工可能會把這些當做晉升的檢查表。這樣很容易一葉障目不見泰山，導致大家迷失在細節中而忘了不同層級之間的本質區別。
寫得像演算法一樣
。一些技術公司似乎認為自己可以建立一個客觀的、機械化的流程。對不起，但人的管理永遠都是混亂且多少會有些主觀性的；你最好把工作階梯寫得人性化一點，要有雄心勃勃的目標，聽起來模糊但卻是真實可靠的。
我針對軟體工程師制訂的工作階梯
我傾向於按照所有權和責任範圍而不是既定的技能程度制訂工作階梯。我之所以偏好這種模式是因為它跟任務分解和分配方式匹配得很好，而且不同層級之間也有著明顯的不同。
當然，技能仍然非常重要。所有軟體工程師都必須能夠寫程式碼並且在團隊環節下解決客戶問題。我發現的一些基本特質包括：
程式設計能力
：編碼、設計、測試、系統維護，
溝通
：有效郵件和Slack通知，前瞻性的狀態更新，結構化的基於事實的論斷，協作。
批判性思維
：平衡短期需求與長期目標的矛盾；思考可能會出錯的地方；找到需求。
主動性
：有活力、主人翁精神、做事有頭有尾堅持到底。
不過話又說回來，這些能力之間其實也沒有明顯的“階梯函式”級的差異，你隨便拿出一項技能就能夠說“啊哈！這意味著你是2級而不是3級水平！”我的工作階梯假設的是這些特質重要，但避免特別的指引。
唯一的例外是4級（及以上水平）工程師；這個層級及以上需要非常深厚和特殊特殊的技術和架構性經驗。
1級
外部頭銜
：［初級］軟體工程師
角色
：開發定義好的功能，調查和修復bug，寫測試。溝通進展情況，識別阻塞問題。找到工作生活平衡。
反模式
：糟糕的程式碼質量。缺乏上進心；需要有人告訴自己接下來該做什麼。經常轉到無用的事情。更願意發牢騷而不是擼起袖子加油幹。通常很無奈。無視團隊進展。
經驗
：0到3年
初級工程師可以給公司帶來很多的原始活力和潛能。他們做你交給他們的工作——往往是很多的工作。不過他們需要幫助，要有預先的專案計劃，要把任務分解成特定的工作細項。團隊領導需要經常檢查一下，確保他們沒有偏離方向。
我更願意給他們的頭銜時“軟體工程師”（把“初級”去掉），因為沒人希望被叫做“初級”。在內部你可以叫他們1級工程師，這並沒有冒犯之意。
我發現1級工程師的面試是最難安排的，因為候選人的技能水平都差不多。
主動性和批判性思維
是最重要的，但這些特徵很難在1、2小時內就判斷出來。2年內沒法晉升到2級的1級工程師就讓他們走吧。
2級
外部頭銜
：［資深］軟體工程師
角色
：負責某個功能領域。把大型請求分解為子任務，提交更高層的狀態更新。編寫測試計劃。承擔運營責任。制定可衡量目標，並且達成目標。稽核程式碼變更。幫助導師招聘新人。
反模式
：消失到對企業不重要的專案當中。無法識別或者溝通大的障礙。區別你我的工作態度。不斷低估時間表。不認真對待卓越運營。解決方案過於複雜。
經驗
：約1到8年
2級工程師可以負責某個重大的軟體很大一部分。你可以信任這些人，他們可以把鬆散定義的請求做對——分解負責任務，做出合理決策，而且在定期檢查間相當獨立地自主工作。
溝通和批判性思維
是必須的技能。
這些人應該叫做“軟體工程師”還是“資深軟體工程師”呢？我持中立態度，但傾向於2、3級工程師的名片和LinkedIn上面都用“資深軟體工程師”的頭銜，而內部就按層級稱呼他們。
儘管有的2級工程師可以當好幾年，但最終他們應該能證明自己可以承擔更多的責任並晉升到3級，否則的話就離開組織。
3級
外部頭銜
：資深軟體工程師
角色
：對整個產品或者大型專案的開發和推出負責。責任流程（Scrum、TDD等）。編寫技術規範，在開始重大專案前識別風險。制定標準。想方設法減少複雜性。根據需要，承擔額外的“技術領導”責任來推動主動完成。
反模式
：傲慢的蠢人。不授權。總是說“是”把自己搞的筋疲力盡。沒喲最細考慮就著急做。不注意細節。無法提高對專案風險或者人事問題的意識。不遵循新技術或者行業趨勢。
經驗
：約5+年
3級工程師對整個產品（比如整個應用或者整套服務）負責。除了交付可靠、可維護的軟體以外，他們還了解公司動態和好的流程是什麼樣的。
資深工程師往往還要額外戴一頂“技術領導”的帽子。這意味著他們要承擔（吃力不討好的）專案管理和流程監督的工作。他們要保證列車準點執行。注意，技術領導並沒有直接上級也沒有老闆，他們完全是靠責任感來做事。
4級（及以上）
外部頭銜
：架構師（或首席工程師，或發明個很酷的頭銜）
角色
：負責跨團隊共享的的基礎設施。跟CTO及其他架構師一起選擇新的技術，促進文化/流程。在關鍵業務領域具備深厚的技術專業知識。進行認真的調研來評估和測試選項。理解可靠性、伸縮性、營業成本、組織容易採用、招聘等的影響（以及權衡）。
反模式
：過於強調伸縮性或高可用性而不是業務需求。花費太多的時間追求最新的“亮點”技術。不協作或者提出問題。居高臨下。有“寵物”議程。厭惡資深領導。
經驗
：約8年以上
4級工程師是能夠評估系統級平臺決定設定長期的公司級技術戰略的架構師。他們往往有兩種角色，既是某功能團隊的獨立貢獻者，也是跟CTO合作的架構稽核人員。你的架構師應該是謙遜的，外向的；他們是你工作上的拉拉隊。
其他工作階梯
當然，這裡設定工作階梯只是其中的一種，你可以跟其他出色的部落格比較一下。這裡就有一些：
Gilt
Rent the Runway
Foursquare
Fog Creek （Joel on Software）
以下這些領域你會看到不同的觀點：
獨立貢獻者的職級應該有多少種？（3？6？）元老級的那些傢伙應該如何對待？
工作階梯應該規定得多詳細？（這牽涉到複雜的分數制度、電子表格矩陣、文章段落，或者只是幾條一般指導）
“技術領導”的角色和責任是什麼？
誰負責專案管理？
相關建議
什麼時候需要建立工程工作階梯？
要我說等到你有5到10位軟體工程師並且開始考慮找人當全職經理時，就應該開始考慮明確工作角色和職業路徑了。
誰來編寫工作階梯？
讓一個委員會從頭開始編寫一份好的工作階梯是很難的。我建議先找一位工程經理寫好草稿，然後交給工程管理團隊進行討論和研討。另一個辦法是讓所有的過程經理各寫一份草稿，然後碰頭比較一下，再由委員會合並。
頭銜很重要
即便有人真誠地告訴你“頭銜不重要，”其真正含義也只是說“目前這個時候頭銜不重要。”隨著公司的發展，職級設定是不可避免的；頭銜可以用來作為職級的代表，要求要有相應的薪水和職業選項。當你換工作時，招聘和工資薪酬也要以你的上一份工作作為參考。
永遠都要確保寫清楚你的頭銜和角色。
工資跟職級繫結，用股權激勵表現
要當成你要把它貼辦公室門口一樣管理工資
—M。 W。 Mantle，《知人善用，Managing the Unmanageable》
僱主應該基於行業可比資料針對每一個職級都建立一個薪水範圍。基於基本工資水平，或者用大幅加薪來獎勵一流表現者的確會限制他們招聘到明星求職者的能力，但這是保證預算在控制範圍並避免不公平的唯一可靠辦法。
予以一次性股權授予並設定未來的最短生效期是比較好的做法，比方說授予2年期權每年行權就是獎勵特別出色員工的一種手段。這向關鍵員工表明即便你不能給予大幅加薪，但你仍然非常重視他們的貢獻並且希望他們留下來繼續一起奮鬥。
提拔看能力而不是資歷
提拔一般不是獎勵其過去的表現。相反，管理層提拔的是那些展現出解決下一級的更大更棘手問題潛能的人。
—Ray Weiss，《技術生涯導航員（ The Technical Career Navigator）》
提拔那些已經勝任下一級別職能的人。如果一位2級工程師想要獲得晉升，他們應該展現出可以做3級工作的能力。作為經理你的工作是提供專案給他們，讓他們獲得初步經驗（並且在他們不大勝任的情況下保證專案的軟著陸）。
不要讓大家以為晉升只是時間的函式，或者對能力不夠的人開啟晉升大門。
不必要求計算機科學學位
就1-3級工程師而言，我並沒有發現正規教育是成功的可靠預測指標。我就見過好幾個表現出色的人是自學成才的，或者是參加了6個月的職業編碼學習後過來的。我不再要求應聘者具備CS本科學位，而且面試的時候也不再問一些偏重演算法的問題了。
4級（首席）工程師角色是例外；這個角色在演算法、系統、架構等等方面需要有可靠的學術基礎。
第三方適用工作階梯嗎？
不；他們是受僱方。你對他們的評估不在於他們的能力水平，而在於他們是否完成了特定專案。
實習生適用嗎？
再次強調，實習生不在工作階梯範疇，因為你沒有當全職來僱傭他們。對於實習生我的原則是這樣的：
你開展實習生計劃的原因是想從中物色好的苗子次年招聘為1級工程師。（當然也有其他一些好處，但這是主要原因）
因此，僅招聘那些準備畢業並且次年要就業的那些實習生。避免大二學生和畢業生，因為這些人未必會留下來。
招聘實習生的條件是：這個人明年能否達到我們初級工程師的招聘門檻？避免招那些態度冷淡的人；好的學生表現的確非常突出。我通常會挑選那些已經寫過不少程式碼而且討論起來總是很興奮的人，比方說在Github上有業餘專案的那些。
最後思考
員工希望瞭解自己在組織裡面的位置。有一個職業的里程碑，把期望和目標都寫得清清楚楚會讓每個人的工作都變得更加容易。
編寫工作階梯的時候，關鍵要：
職級跟公司的組織方式匹配（角色、彙報結構）。
招聘和晉升的條件跟公司價值觀一致。
保證公平。
制定了工作階梯後你也可以在今後調整角色和評估標準；但是一定不能違反公平性原則。每個人都必須堅持一致的標準，否則你計程車氣和生產力就要崩潰。一份好的工作階梯能夠創造出公平的職場競爭環境，為比賽設定好規則。
原文連結：
編譯組出品。編輯：郝鵬程。