編者按：初創企業在早期一般都是人人身兼數職，倡導扁平化的管理，并不怎么看重頭銜。但是隨著組織的擴大，初期的這種管理模式會引起諸多問題。身兼軟件工程師、經理與創始人角色的Chuck Groom從個人經驗出發，分析了設定工作階梯的好處，并提出了他的建議。無論是創業公司管理人員還是軟件工程師都可以參考一下。

[[224139]]

軟件公司應該審慎地考慮工程崗位職級的設置，制定好一個工作階梯，向員工解釋清楚對其的希望，不同角色之間的區別，以及職業發展的領域。

在本文中，我將討論為什么制定工作階梯可以幫助到每個人；好的工作階梯應該是什么樣的；我對軟件工程師職級是如何思考的；最后我還會提供一些建議。盡管本文的受眾是管理層，但工程師看了之后也應該能從公司的角度去思考而獲得一些洞察。

注意，本文僅討論獨立貢獻者（IC）的工程發展路徑。其他并行的發展路徑（管理、產品）包括轉崗均不在本文討論之列。這些話題都值得討論，但不在本文范疇之內。

是的，工作“階梯”的想法有點奇怪

[[224140]]

工作“階梯”這種說法暗示了所處行業的高度結構化、非常穩定的，有著抵達某個有意義的終點的長期路徑，就像成為合作伙伴那樣。但是現代的職業流動性更強發展方向更加多樣。員工往往每幾年就要變動一下工作。

不要把職業階梯看成是長遠的人生規劃。這樣你會把太多關注放在階梯頂部（“我究竟應該怎么過我的一生？”），但這是你下一步的關注重點。階梯就是個工具，讓你設定好對未來幾年的期望。

假設你沒有工作階梯

新公司或者團隊往往對頭銜或者角色沒有很好的定義。實際上，這他們也許反而會引以為豪；你應該聽說過“我們是一家扁平化的組織”，“頭銜并不重要。”盡管大家的薪水可能很不一樣，但大家普遍感覺這是英才管理的模式。

好吧，如果沒有工作階梯地球也照轉的話，為什么要自找麻煩改變這些呢？我們可以看一些例子。

• 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. 你開展實習生計劃的原因是想從中物色好的苗子次年招聘為1級工程師。（當然也有其他一些好處，但這是主要原因）

2. 因此，僅招聘那些準備畢業并且次年要就業的那些實習生。避免大二學生和畢業生，因為這些人未必會留下來。

3. 招聘實習生的條件是：這個人明年能否達到我們初級工程師的招聘門檻？避免招那些態度冷淡的人；好的學生表現的確非常突出。我通常會挑選那些已經寫過不少代碼而且討論起來總是很興奮的人，比方說在Github上有業余項目的那些。

最后思考

員工希望了解自己在組織里面的位置。有一個職業的里程碑，把期望和目標都寫得清清楚楚會讓每個人的工作都變得更加容易。

編寫工作階梯的時候，關鍵要：

• 職級跟公司的組織方式匹配（角色、匯報結構）。

• 招聘和晉升的條件跟公司價值觀一致。

• 保證公平。

制定了工作階梯后你也可以在今后調整角色和評估標準；但是一定不能違反公平性原則。每個人都必須堅持一致的標準，否則你的士氣和生產力就要崩潰。一份好的工作階梯能夠創造出公平的職場競爭環境，為比賽設定好規則。