塑造文化#

當你身處資深工程領導者的角色時，設定團隊文化是你職責的一部分。初次擔任 CTO 的人常犯的錯誤，就是低估了對工程團隊文化保持清晰與深思熟慮的重要性。無論你是在建立新團隊還是改革既有團隊，忽視團隊文化必然會讓你的工作更加困難。隨著團隊成長與演進，你需要像照料任何重要基礎設施一樣，持續關注你的文化。

作者在 Rent the Runway 有機會從零開始建立工程團隊的許多文化元素。由於加入時團隊仍處於經典的、無結構的「草創新創」模式，她能夠引進許多文化結構與實踐。這個過程對她來說是極好的學習經驗。

結構的價值#

對許多受新創文化吸引的人來說，「結構」和「流程」這兩個概念輕則被視為毫無意義，重則被認為有害。作者見過新創團隊的調查，提到引進結構時，受訪者的反應包括「緩慢」和「扼殺創新」。他們相信結構正是大公司行動遲緩、滋生官僚、成為聰明人不願待的無聊地方的原因。

技巧： 與懷疑者討論結構時，可以重新框架這個議題。不談結構，談學習；不談流程，談透明度。我們設立系統不是因為結構和流程本身有什麼內在價值，而是因為我們想從成功和錯誤中學習，並以透明的方式分享那些成功、編碼從失敗中學到的教訓。這種學習和分享，正是組織隨時間變得更穩定、更可擴展的方式。

作者希望幫助讀者建立關於公司文化的個人哲學，同時提供設定流程和結構的方法。如果你想創造健康的團隊，你需要理解什麼對你、對你的公司、對你不斷成長的同事群體是重要的。不只思考你在乎什麼，還要思考如何在公司和團隊成長演進時，有效地擴展那些知識和努力。

早期新創的特性#

早期新創吸引的是能夠承受極高不確定性和風險、同時換取同等高度自由度的人。公司能否成功甚至能否長期存在都沒有保證。市場可能尚未驗證，訊號好壞參半，可能面臨激烈競爭。而且幾乎沒有既有的基礎可以建設——程式碼尚未撰寫，商業規則尚未建立。從選擇技術框架到辦公室裝飾，一切都有待決定，而許多初始決策在穩定下來之前會被推翻好幾次。

對領導者來說，在早期最重要的事情是：選定一個策略並執行。 在大量選項面前培養果斷力。你有問題？找出解決方案並修復。那個方案行不通？試別的。你不需要找到完美的解決方案，只需要找到能讓你撐到下一個里程碑的方案——無論那是下一次發布、下一次成長爆發、下一輪融資還是下一位新員工。

無結構的暴政#

有些公司選擇限制決策本身——例如不使用職稱。不設職稱在某種意義上是一個決定，但同時也意味著你永遠不需要決定某人的職稱、不需要擔心晉升、不需要建立處理未來職稱決策的機制。決定「現在先不決定」對新公司來說是很受歡迎的選項，因為在少數幾個人的規模下，這確實無關緊要。

關於組織政治最精闢的文章之一，是 Jo Freeman 的《無結構的暴政》（The Tyranny of Structurelessness）。雖然這篇文章討論的是早期女性主義/無政府主義集體，但 Freeman 的洞見同樣適用於新創文化。假裝缺乏結構，往往會創造出隱藏的權力結構——這源自人類溝通的本質，以及試圖擴展那種溝通時面臨的挑戰。

Freeman 描述了無結構團體能夠運作的一組條件：

這段描述恰好是許多早期新創的常見情境。即便整體公司已超出小團體的規模，工程團隊仍常常逼迫自己維持無結構狀態——僱用「全端」工程師、全部從現有團隊的職業和社交網絡中招聘（低技能專業化與高同質性）、強制團隊聚集辦公（降低溝通障礙）、讓工程團隊完全作為產品或創辦人的執行部門（高度任務導向）。

重點： 無結構的團體要嘛展現出使其實際上不如成員所願那般自主的特性，要嘛就是由隱藏的階層與權力動態所運作。在許多情況下，兩者都在某種程度上同時為真。

無結構的例子同樣適用於技術決策和流程。早期新創中常見大量的義大利麵式程式碼（spaghetti code），這並非偶然——當工作是為了滿足即時任務、在統一的程式碼庫中由一群可互換的人執行時，結果通常不是更大的深思熟慮的結構，而是這裡修修、那裡 hack，只求把事情推進。當我們想讓程式碼可擴展時，往往需要重構——而重構正是識別並明確拉出結構的過程。

這就是結構的價值。結構是我們擴展、多元化、承擔更複雜長期任務的方式。 我們對軟體這樣做，對團隊這樣做，對流程也這樣做。正如優秀的技術系統設計師能夠識別和塑造底層系統結構，強大的領導者能夠識別和塑造底層團隊結構與動態。

結構不宜過早也不宜過晚#

沒有什麼比一個有著僵化階層的五人小團隊更荒謬的了——五個人排成一條指揮鏈，第五個向第四個報告，第四個向第三個報告，以此類推。同樣地，如果一個掙扎中的五人團隊把大部分時間花在開會決定廁所要用哪種衛生紙，他們的優先順序顯然有問題。結構來得太早會造成傷害，讓一個本應專注在其他事物上的團體慢下來。

然而，更常見的是結構來得太晚。問題會悄悄滲入——一個人習慣了做所有決定並經常改變主意。當只有他和幾個人時這行得通，但當團隊擴展到 10 人、20 人、50 人時，你開始看到高度的混亂和浪費。他改變主意的成本變得越來越高昂。

評估你的角色#

認清你所駕駛的載具大小。這取決於以下因素的組合：

Gall 定律#

結構隨著公司的成長和老化而增長。John Gall 在 Systemantics 一書中提出了一條定律：

補充： Gall 定律——一個能運作的複雜系統，必定是從一個能運作的簡單系統演化而來的。從零開始設計的複雜系統永遠無法運作，也無法修補使其運作。你必須從一個能運作的簡單系統重新開始。

你的公司起初是一個包含幾個人的非常簡單的系統，隨著更多的人、規則和基礎設施被加入，它演化成了一個複雜系統。在團隊小且運作良好時，過度設計團隊結構或流程沒有太大好處。然而，在某個時間點你會開始經歷失敗，而失敗正是調查和識別結構需要改變的最佳場所。

從失敗中學習結構#

作者對領導者的建議很簡單：當失敗發生時，檢視所有導致失敗的現實面向。 你看到的模式就是演進結構的機會——要嘛創建更多或不同的結構，要嘛移除結構。思考失敗發生的頻率和代價，運用你最好的判斷來決定需要做出什麼改變。

用失敗來引導演進，讓你能在正確的層級應用結構。如果失敗只發生在系統的某個部分——比如某一個團隊——你可以嘗試只針對那個團隊調整結構，而不需要改變更大的結構。

那麼從成功中學習呢？你確實可以從成功中學到東西，但成功往往是個糟糕的老師。諷刺的是，雖然運氣在失敗和成功中都扮演角色，我們傾向於將失敗歸咎於壞運氣、將成功歸功於自己的行動。因此，我們較不可能基於從失敗中學到的教訓而過度結構化團隊。成功則誘惑我們相信那個「銀彈」——那個能讓一切變好的奇妙訣竅。

注意： 如果你想從成功中學習，確保你能識別在更廣泛地應用那些教訓時真正尋求的具體改善，並且你理解重複那種成功所需的背景脈絡。

失敗即學習的機會#

當每位新人因為缺乏 onboarding 流程而拖慢團隊數個月——這是缺乏結構導致的失敗。當員工因為沒有晉升路徑或職涯成長管道而經常離開公司——這是缺乏結構導致的失敗。當第三次因為有人直接登入資料庫、意外刪除了關鍵資料表而造成生產環境停機——這是缺乏結構導致的失敗。

作者偏好用學習和透明度來取代「結構」這個詞，因為真正在做的是識別失敗的原因——特別是頻繁的失敗——並試圖找出可以改變什麼來解決這些失敗。這根本上就是在學習。

創造你的文化#

文化是人們不需要思考就知道該怎麼做事的方式。 — Frederick Laloux，《Reinventing Organizations》

文化是建立新創時經常被討論的話題。公司的核心價值是什麼？公司文化是什麼樣的？新人是否「文化契合」（culture fit）？「文化契合」是否是歧視性招聘做法的暗語？

文化的本質#

作者深信文化是真實存在的，也極為重要，但很多人完全不理解它。文化既是公司演化的自然、容易的結果，也是如果你不去照料就會迅速成為問題的東西。有意識地引導團隊文化是領導者職責的一部分。

那麼，文化是什麼？文化是一個社群中普遍不言自明的共同規則。 美國文化規定握手是一種問候方式，而在某些其他文化中，觸碰陌生人被視為非常奇怪。你如何稱呼不同地位或與你有不同關係的人，這是你文化的一部分。文化不意味著每個人都持有完全相同的價值觀，但它傾向於引導一種普遍的重疊，並創造出一堆互動規則——如果你深深融入那個文化，你不太需要去思考這些規則。

人們確實會使用文化價值以外的方法做決策——他們可能遵循正式或非正式合約的標準，或進行純粹的數據驅動分析。但在複雜環境中，當團體需求必須凌駕於個人需求之上時，文化價值是讓我們能作為團隊合作、在面對不確定性時做出決策的黏合劑。 這就是為什麼釐清和引導你的文化是建立成功公司如此重要的部分。

文化不是可以完美規劃的#

如果你正在組建一家新公司，無法保證一個預先設計的健康文化會自然形成。你可能希望創建一個志同道合者的規劃社區，但現實遠比這混亂得多。現實更像是一場求生競賽，文化要嘛是事後才想到的、要嘛是事後才加上的正當化理由。早期員工會塑造文化——無論好壞，或者最可能的，兩者兼具。

不是每個人都適合每家公司。越早認識到這一點越好。有時候我們害怕擁有核心價值，因為我們相信它們會造成歧視。但作者認為，經過深思熟慮創建的、真正是價值觀的一組價值觀，應該能減少科技公司中常見的那種表面歧視，轉而創建一個真正共享核心原則和溝通方式的員工社群。

重點： 「從 MIT 畢業的工程師」不是一種文化。「重視技術創新、努力工作、智慧、科學方法和數據的人」才可能是。前者只允許極其狹窄的一部分人通過，後者則允許更廣泛的人群加入，同時確保這些人確實擁有相同的價值觀。

核心價值的影響#

如果你加入一家有核心價值的公司，那些價值很可能是由創辦人（或創辦人和早期員工）建立的，因此反映了公司的文化。這很重要，因為無論你是否意識到，你都會被衡量是否符合這些價值。創始團隊的價值觀會在公司內部被強化、被認可、被獎勵。

• 真正擁抱並展現公司所有核心價值的員工往往自然地表現出色。對他們來說契合是容易的——他們可能會壓力大或工作過度，但他們受人喜愛且通常感到快樂。
• 不那麼容易匹配所有價值的人會面臨更大的困難。這不意味著他們會失敗，但會有更多摩擦，融入和被接受可能需要付出更多努力。

這對你有什麼影響？如果你是技術高管、共同創辦人或 CTO，這些資訊有深層的應用。如果你加入或創建一家與你自身價值觀非常不同的公司，你會感受到極大的摩擦，讓你的生活更加困難。在最高層級，所有的文化對齊都會在你所做的一切中發揮作用，因為你花費大量時間在談判、協作和跨職能團隊合作的領域。

應用核心價值#

無論你是否處於創始或高管位置，理解和培養文化都是你作為領導者工作的關鍵部分。以下是一些建議：

定義你的文化#

如果你有一套公司價值觀，將這些價值觀映射到你的團隊上。你可以增加幾個對你團隊特別重要的價值觀，或以對你團隊有意義的方式詮釋那些價值觀。例如，作者在 Rent the Runway 的技術團隊明確重視多元性——這意味著他們更關心你能做什麼和你的潛力，而非讓你通過一系列篩選清單。他們在公司價值觀之上疊加了學習文化，因為他們認為這對工程師來說很重要。

每個子團隊都會有自己略微獨特的文化。有些團隊專注於專業，上下班時間很規律，工作方式非常有條理。有些團隊偏好較晚或較早的工作時間，或較不正式的會議文化，有更多聊天和社交互動的空間。

強化你的文化#

透過正面方式獎勵展現文化價值的人來強化你的文化：

• 人們可以在公司全員會議上分享核心價值故事
• 在技術部門全員會議上，讓大家互相 shoutout，表彰那些超越期待的同事
• 績效考核的一個重要用途就是評估團隊成員的價值觀與公司價值觀之間的對齊程度

技巧： 即使你不擅長公開讚美他人或分享感受，也要努力突破。穿越你害羞的那一面，進入你真心關心同事的那一面。你可以用不做作、不虛假的方式分享這些故事。我們作為社群所講述的故事，將我們連結在一起。

識別價值觀衝突#

學會發現與公司或團隊存在價值觀衝突的人：

• 如果你的公司有「捲起袖子親自參與」的價值觀，那個不斷把工作推給別人的隊友就沒有真正遵循這個價值觀
• 如果你有「快樂和正面態度是一種選擇」的價值觀，那個對每個想法潑冷水、批評一切的隊友就會有融入的問題

有時候人會改變來採納這些價值觀。作者自己來自一個相當專業且批判性的工作文化，但學會了欣賞以正面的眼光看待事物的價值。這不意味著她失去了批判性的眼光，只是這從來不是她最容易採納的價值觀。用核心價值來指導那些不對齊的人，可以幫助你表達那些原本可能只是模糊摩擦感的東西。

將價值觀融入面試流程#

提醒你的面試官團隊的價值觀，並請他們明確留意面試者似乎與這些價值觀匹配或衝突的地方。

注意： 很多面試試圖透過「友誼」標記來判斷文化契合，例如「你願意跟這個人一起困在機場嗎？」你當然不想僱用團隊無法忍受的人，但文化契合不是在僱用朋友。以友誼測試來判斷文化契合幾乎必然會帶有某種形式的歧視——人類傾向與擁有相似背景經歷的人建立友誼，而這些經歷往往與教育程度、種族、階級和性別高度相關。

不要在討論契合度時含糊不清，要具體。 這個團隊的價值觀是什麼，你在哪裡注意到匹配或不匹配？一位非常聰明但極度重視獨立的工程師，可能不適合一個所有人都必須在所有專案上大量協作的團隊。一個相信最有分析力的論點永遠應該勝出的人，可能無法在一個重視同理心和直覺勝過純粹分析能力的公司中運作良好。

理解你公司的價值觀、你團隊的價值觀，以及你個人的價值觀。將它們寫下來，嘗試做到明確。用這個明確的清單來評估候選人、讚揚團隊成員，以及指導你的績效考核流程。

創建文化政策#

創建文化政策文件可能很困難，因為從零開始撰寫這些文件本身就很難。幸運的是，越來越多的人公開分享他們的政策和流程——從職涯路徑到薪資標準到事件管理。然而，僅僅有一個起點並複製它並不總是足夠的。

職涯階梯的失敗案例#

作者在嘗試推出第一版工程職涯階梯時深刻體會了這一點。驅使她建立職涯階梯的失敗，源於 HR 團隊在為工程團隊做薪資審查時，她意識到完全沒有薪資結構。因為缺乏結構，大多數人的薪資是基於前一份工作的薪資和談判能力的組合。此外，他們很難判斷應該招聘什麼樣的人——他們只招「資深」工程師嗎？那意味著什麼？管理或其他角色呢？

在 HR 團隊的推動下，她著手建立職涯階梯。她向經營其他新創的朋友借了一份——八個級別，從初階工程師到高管，分為四個類別：技術技能、完成任務、影響力、溝通與領導力。她拿了這份階梯，增加了一些細節，重新命名了級別，然後推出。

結果第一版階梯徹底失敗了。

為什麼一份似乎在朋友那裡運作良好的階梯在她這裡慘敗？她推測原因在於兩家公司之間的巨大差異。她的團隊成員背景非常多元——主要來自小公司和新創，少數來自大型金融公司，只有幾個人主要在大型科技公司工作過。因為工作經驗如此多元，沒有真正的共享文化習慣可以依賴。而她朋友的團隊則有一個非常龐大、強大的核心群體，所有人都曾在同一家大型科技公司工作，因此有更多不需要被明確說明的共同理解。

重點： 這個故事的關鍵教訓是——在一家公司成功的做法不一定能轉移到另一家公司，即使兩家公司有很多共同之處。她的第一版階梯失敗是因為她的團隊需要更多細節。輕量級階梯的目標是讓團隊不要過度關注自己的級別和晉升，但缺乏細節反而導致許多人更加執著。工程師們爭辯說他們應該在更高的級別，因為描述太模糊了。

撰寫職涯階梯#

以下是為你的組織撰寫職涯階梯時需要考慮的重要議題：

徵求團隊參與#

不要自己一個人做。請資深經理和工程師提供回饋和細節。請人指出他們不理解的地方，提出修改、補充和編輯的建議。以小組方式討論，讓子團隊負責他們最關心的部分。例如，最資深的個人貢獻者可以負責個人貢獻者級別的技術和技能期望。

尋找範例#

從其他公司的朋友那裡收集更多階梯範例來提供想法。現在有很多好的公開資源可以使用。最好的細節往往來自較大的雇主，特別是那些擁有強大技術聲譽的公司。解釋非常資深技術級別的工作範圍可能很困難，而來自大公司的範例確實有助於將細節付諸文字。

注重細節#

撰寫好的階梯最大的挑戰之一是勾勒出細節。你需要的東西既能啟發人心又具描述性，同時匹配你的公司。讓一家 50 人工程團隊的新創總監管理整個部門沒有意義，但在大型跨國公司可能合理。思考你在決定某人是否應該被僱用到某個級別或晉升到某個級別時會尋找的細節，並將這些細節適當地納入。

同時使用長篇描述和摘要#

將階梯分成兩份文件：

• 簡要試算表版本： 讓你可以並排查看各級別屬性，了解它們如何隨著級別提升而演進。撰寫時可以看到如何從一個級別建構到下一個級別，以及角色的範圍、技能和責任如何擴展。
• 長篇版本： 可以為每個級別講述更完整的故事。不僅僅是將級別視為一組技能和屬性，長篇階梯讀起來有點像一份在該級別表現良好的人的績效評估。你和你的員工可以看到這些技能如何協同運作來構成一個完整的角色。

薪資與階梯的關係#

HR 部門會希望使用職涯階梯來幫助設定薪資期望。通常每個級別都有一個薪資帶（salary band），即該級別人員可獲得的最低和最高基本薪資範圍。

• 少級別 → 需要很寬的薪資帶來涵蓋同一級別中表現差異很大的人
• 多級別 → 可以快速晉升並給予加薪，同時保持同一級別所有人的薪資接近。但在相近的級別之間創造足夠的區別來讓人容易分辨級別是極其困難的

早期職涯提供頻繁的晉升機會#

有些人建議在階梯的前段設置較多級別，以對應早期職涯工程師期待頻繁加薪和晉升的事實。你可能希望在某人職涯的前兩到三年能每年晉升一次。如果是這樣，就創建幾個涵蓋軟體工程師角色的級別，並為這些級別提供相對較窄的薪資帶。

寬薪資帶適用於級別較少時#

寬薪資帶和少級別能在各級別之間做出更清晰的區分，應該更容易辨別誰在哪個級別運作。在級別間距較大的情況下，你需要大的薪資帶，而且要讓薪資帶重疊。例如，軟體工程師的薪資帶可能是 $50-100K，資深軟體工程師的薪資帶可能是 $80-150K。這意味著一位表現出色的軟體工程師可能比一位資深工程師薪資更高。你需要這個彈性空間來留住那些在當前級別表現良好但尚未準備好承擔下一級別額外責任的人才。

考慮斷點級別（Breakpoint Level）#

許多公司有某些級別被視為「不進則退」（up or out）。這些是早期職涯角色，缺乏晉升意味著此人尚未達到留在公司所需的成熟度或獨立性。

• 斷點級別是人們可以永久停留的最低級別——永遠不晉升但也不算表現不佳。對許多公司而言，這大約在資深工程師（Senior Engineer）級別。達到這個級別的人是穩固的團隊成員，但可能出於自己的選擇而永久留在這個級別。
• 預期你的團隊會聚集在這個級別周圍，上面和下面的人都較少。

認可成就#

有些公司想保密級別，但這往往是不可能的——人們會談論。不過你可以特別強調某些級別。作者建議至少有一些級別是里程碑式晉升（keystone promotions），值得公開分享和慶祝：

• 晉升為資深工程師（Senior Engineer）
• 晉升為 Staff Engineer
• 晉升為 Principal Engineer（如果有的話）
• 管理路線上，晉升為 Director 和 VP

擁有不太靠近的里程碑級別，給人們一個超越下一次加薪的更大成就目標，並讓這些級別從更宏觀的職涯角度保持其重要性。

分離管理軌道和技術軌道#

在現代，你需要管理和個人貢獻的分離軌道。你不希望人們覺得唯一的晉升路徑是管理人員，因為不是每個人都適合那個角色。通常在資深工程師之上開始區分管理級別和技術級別。

注意：你不應該期望資深技術級別和資深管理級別有相同數量的人。資深管理通常是由人數量驅動的需求——你需要足夠的主管來管理團隊中的人。資深技術則取決於你的團隊和產品所需的技術領導力的複雜性和範圍。

考慮將人員管理技能作為中階職涯要求#

鼓勵每個人在有資格被晉升到軌道分叉點以上之前，都要有某種管理或指導經驗。即使在設計軟體時，你也在與其他人類和人類需求打交道。優秀的資深個人貢獻者仍然知道如何管理專案和指導團隊中較資淺的成員，因此可以考慮將領導力經驗（通常透過擔任 tech lead）作為晉升到資深個人貢獻者級別的要求。

年資的考量#

沒有人喜歡設置人為的障礙，而年資可能感覺是最人為的障礙。但作者建議在這個議題上要明智。在她的階梯中，她以成熟度增長的期望來區分里程碑級別，這些往往與行業中的年資以及（在較小程度上）年齡相對應。

例如，成為 Staff Engineer 需要大量的個人成熟度來思考大型專案——這是 Staff Engineer 的區別特徵。成為出色的程式設計師不足以成為偉大的 Staff Engineer，你需要展示完成和支持一些長期工作的成果記錄。你不必將年資作為級別的嚴格要求，但考慮一些經驗法則，特別是在你第一次撰寫階梯和推出級別時。

不要害怕隨時間演進#

當你撰寫這樣的階梯時，你正在創建一份活文件，它需要隨著公司成長而演進。你可能會遺漏一些細節。例如，作者的階梯對於前端開發者來說很難解讀，因為她自己偏重基礎設施開發，所以他們需要調整以更好地反映在那個領域中成為資深表現者的意義。

技巧： 好的階梯是招聘、撰寫績效考核和晉升流程中的關鍵元素。如果你有機會創建這樣的文件，不要害怕讓你的團隊參與。最好的流程和文件反映的是團隊整體，而不僅僅是你當下的偏見。在小公司設立這些階梯的最大好處之一，就是你可以在不經過大量官僚程序的情況下讓很多人參與進來。

跨職能團隊#

誰是你的工作夥伴？你向誰報告？你與誰協作？這些答案在極小的公司（答案：所有人）和非常大的公司（答案：有一套在你加入之前就建立好的清晰結構）中都很明顯。作為成長中公司的領導者，你至少需要為你的團隊和公司回答這些問題一次，而且很可能是多次。

Rent the Runway 的跨職能實驗#

作者在 Rent the Runway 的經歷中，見證了產品工程組織的演進。她加入時，工程團隊大致分為兩組：店面團隊（所有面向客戶的網站開發）和倉儲團隊（支持倉庫運營的軟體）。他們很快將店面團隊演化為前端和後端，因為正在從 PHP 單體應用重寫為基於 Java 和 Ruby 的微服務架構。

在她第一年快結束時，他們進行了一個實驗。為了建立一個新的客戶功能——基於客戶照片評論的功能（讓購物者看到其他客戶上傳的穿著禮服的照片，連同身材資訊），他們創建了一個跨職能團隊，包括：

• 專精前端使用者體驗的工程師
• 後端服務的工程師
• 產品經理
• 設計師
• 數據分析師
• 甚至客服團隊的代表

這個專案取得了巨大成功。他們快速交付了好的功能，所有貢獻者都感到他們理解了專案的目標，並且因為這個跨職能團隊而能更好地工作。在此之前，他們一直深陷「我們 vs 他們」的模式——你特定的業務職能是「我們」（技術、產品、分析、行銷等），組織的其餘部分是「他們」。創建這些協作單元讓人們有機會將整個群體視為「我們」。

這是一個在組織健康方面的明顯勝利，因此他們將整個組織演進為所有產品工程都由類似的跨職能團隊執行。無論你叫它們「pods」、「squads」或「pillars」——跨職能產品開發團隊是一種流行結構是有充分理由的。 把一個專案成功所需的所有人放在一個組裡，幫助這些團隊的成員專注於手頭的專案，並使整個團隊的溝通更加有效。

Conway 定律#

Conway 定律常在這類結構的討論中被引用：

補充： Conway 定律：「設計系統的組織……受限於產生與這些組織的溝通結構相同的設計。」當我們組建跨職能團隊時，我們承認最重要的溝通——我們需要優先於一切的溝通——是那些能帶來有效產品開發和迭代的溝通。

注意，這種結構不一定會產生最有效率的技術。事實上，與更以工程為中心的團隊結構的公司相比，它可能會產生一些效率上的不足。因此，如果你採用這種結構，就必須決定在哪些地方你願意承受一些系統設計的妥協，以換取最有效的產品創造。

跨職能團隊的運作結構#

這種「pod」結構的具體運作方式是什麼？一個經常引起焦慮的問題是誰管理誰。

管理結構不需要改變#

當 Rent the Runway 轉向這種團隊組織時，他們沒有改變管理結構。工程師仍由工程經理管理，並向作者報告。產品經理向產品負責人報告。但決定誰在做什麼主要由 pod 本身決定。這意味著你仍然可以從你的工程經理那裡獲得技術指導和監督，但你的日常工作由 pod 路線圖的需求決定。

維持基礎設施團隊#

每個職能都有自己的專注需求。通常工程部門需要有人監督關鍵核心系統，你可能還需要一些專家負責核心網路平台、行動端或資料工程等領域。作者保留了一個小型的基礎設施組織，不被分配到產品開發。

技巧： 即使有專門的基礎設施團隊，分配到產品 pod 的工程師仍需要一些時間來處理工程特定的任務，如 on-call、面試和持續性工程（即技術債）。作者建議保留所有工程時間的 20% 用於此類工作，這純粹基於她的個人經驗和同行在工程管理中的經驗。

大公司也適用#

這種跨職能結構不是小型新創的專利。許多大公司也以這種方式組織團隊。例如，銀行通常有附屬於特定業務領域的技術團隊——管理結構由工程師組成，但路線圖和日常工作由業務部門的需求和其相關工程團隊共同決定。通常有一個集中的基礎設施團隊支持基礎系統以及將被跨公司多個團隊使用的大型框架和技術。

產品導向 vs 技術導向#

跨職能結構的影響是微妙的。這些團隊中每個人的價值觀都會開始改變：

• 在以技術為中心的結構中（工程師只與其他相同「類型」的工程師合作），焦點是按照某種工程卓越的標準成為最好的工程師。設計複雜系統或了解最新 iOS 細節的人是團隊的領導者和榜樣。
• 在以產品為中心的結構中，領導力的焦點改變了。擁有最好的產品 sense、能快速有效地完成功能、與其他職能溝通最好的工程師會開始成為團隊的領導者。

重點： 思考什麼對你的公司或組織的成功真正重要。如果最重要的是發展一個由許多不同業務領域匯集而成的產品，你可能需要擁有商業 sense 的領導者。另一方面，在技術必須穩如磐石或極具創新和尖端的領域，你可能需要更具工程焦點的團隊和能夠設計複雜系統的人來領導。你不必完全走向任何一邊，但要認識到其中一個會主導整個公司——特別是如果你的角色在高層管理——你應該將自己的技能組合聚焦在公司最重視的那一個，並為另一個僱用人才。

建立工程流程#

工程流程是結構真正落實的地方。職涯階梯、價值觀、團隊結構——與採用錯誤的工程流程可能引起的普遍焦慮和挫折相比，這些都相對容易。沒有流程，你的團隊將難以擴展；有了錯誤的流程，他們會被拖慢。平衡團隊當前的規模和風險容忍度與現有流程，是引導良好軟體開發和運營指南的本質。

實用建議：去人格化決策#

隨著團隊成長，你應該考慮添加三個主要流程。所有這些流程在你圍繞它們設定行為期望（而不僅僅是技術細節）時效果最好。

Code Review#

Code review 無論好壞，已是現代標準。一旦你的團隊達到一定規模、有一定數量的人在一個程式碼庫上工作，code review 就是確保程式碼庫穩定性和長期品質的有價值工具。然而，必要的 code review 也會在完成工作的關鍵路徑上，所以你需要讓流程直截了當且高效。此外，code review 常常是工程師彼此表現惡劣的場合——用它作為批評同事或強制執行不切實際標準的平台。

最佳實踐：

• 明確 code review 的期望。 大多數情況下，code review 不會抓到 bug——測試才會抓到 bug。例外是 code review 可以抓到遺漏的註釋或文件更新、遺漏的相關功能變更，審查者有時能判斷新增或修改的程式碼是否有不充分的測試。Code review 主要是一種社會化的練習，讓多個團隊成員看過並了解變更的程式碼。
• 使用 linter 處理風格問題。 工程師可以在風格問題（特別是格式化）上浪費荒謬的時間。這不應該在 code review 中辯論。決定一種風格，把它放進自動格式化程式碼的 linter。允許風格在 code review 中被討論，往往導致吹毛求疵和批評——輕則感覺無生產力，重則構成霸凌。
• 留意 review 積壓。 有些公司對一個人可以被分配多少待處理的 review 請求設有上限，當他有太多待處理請求時，會阻止他再請求 review。思考如何推動這些請求通過系統，以及如何確保每個人的程式碼都得到充分的審閱時間。

故障事後檢討（Outage Postmortem）#

「事後檢討」（postmortem）流程是良好工程的關鍵元素。許多人已開始稱之為「學習回顧」（learning review），以表明其目的不是確定死因，而是從事件中學習。以下是幾個關鍵元素，特別是對小團隊而言：

• 抵制指責和怪罪的衝動。 在壓力大的停機事件之後，指著人問他們為什麼沒有預見到行為的後果是極其誘人的。為什麼他們在那台機器上執行了那個命令？為什麼他們沒有測試？為什麼他們忽略了那個警報？不幸的是，這種指責只會導致人們害怕犯錯。
• 審視事件周圍的環境，理解事件的脈絡。 你想理解和識別促成這個事件的因素。這可能包括尋找能夠檢測到問題的測試，或能讓事件管理更順暢的工具。獲得一份好的環境因素清單有助於你發現模式或改進領域，構成「學習」回顧的「學習」部分。
• 對哪些收穫重要、哪些值得放棄要務實。 注意不要給人留下需要解決在過程中識別的每個問題的印象。許多學習回顧以一長串可以改進的事項結束。你不太可能全部做到，事實上，如果你試圖全部做，你最終可能一個都做不完。挑選一兩個真正高風險且極可能導致未來問題的，並承認你打算暫時放過的那些。

架構審查（Architecture Review）#

架構審查涵蓋團隊可能希望做的所有重大系統和工具變更。目標是幫助將大的變更社會化給適當的群體，並讓這些變更的風險變得清晰。一些可能要求人們準備好回答的問題包括：

• 團隊中有多少人能夠使用這個新系統/撰寫這種新語言？
• 我們是否有針對這個新事物的生產環境標準？
• 推出和培訓人們使用它的流程是什麼？
• 使用它是否有新的運營考量？

指導原則：

• 明確哪些類型的變更需要架構審查。 通常包括新語言、新框架、新儲存系統和新開發工具。人們經常想要架構審查來防止團隊設計糟糕的新功能，但在小公司中試圖夠早地捕捉新功能設計通常不切實際，即使在大公司也很困難。而且這會大大減慢速度——你可能不想在像功能設計這樣的常見活動前面放置繁重的流程。
• 架構審查的價值在於準備審查。 要求對系統的大變更或新增進行審查，迫使人們思考為什麼他們想做這些改變。這些流程的一個價值是幫助人們意識到他們可能沒有考慮到的風險。
• 明智地選擇審查委員會。 你希望審查委員會包含將受變更影響最大的人，而不僅僅是一個靜態的選定的專家組。部分目標是讓你自己從為每個技術決策負責的位置上脫身，另一部分是確保那些需要處理決策結果的人能參與評估。這些決策應考慮更廣泛的團隊，讓更廣泛的團隊認同它們。範圍最好限制在會被決策密切影響的人。沒有什麼比一個來自完全不相關領域的人否決一個專案更令人沮喪的了。

評估你自己的經驗#

在結束這一章時，思考以下問題：

• 你現在有哪些政策？哪些實踐？你有把它們寫下來嗎？上次重新檢視它們是什麼時候？
• 你有公司價值觀嗎？它們是什麼？你如何在團隊中認可它們？
• 你有職涯階梯嗎？你覺得它準確反映了今天的團隊嗎？它反映了你想要擁有的未來團隊嗎？如果不是，你能改進它嗎？
• 對你的團隊來說最令人擔憂的風險是什麼？對你的公司呢？你如何在不給團隊帶來不必要的流程和官僚負擔的情況下，降低這些風險？