在設計工程組織時，我很常思考所謂的「組織數學」（organizational mathematics）：每個團隊配一位經理與六到八名工程師，每位管理經理的經理則支援四到六位經理。從這些數字出發，你能很快推導出一個運作得還不錯的組織結構——它未必完美，但可行。

把這套方法套用到多個組織後，反覆出現的一個邊界案例是：最資深的工程師到底該向誰匯報？按組織數學，他們應該向組織末梢節點的經理匯報；但作為組織的關鍵領導者，他們是否該向更資深的領導者匯報，以取得勝任角色所需的資訊與授權？

不同原型的常見匯報配置#

在回答之前，值得先描述今日各公司最常見的配置，特別是它們如何隨 Staff-plus 原型（archetype）而不同。

• 技術主管（Tech Lead）：通常向負責單一團隊的經理匯報，較少見的情況是向負責兩到四個團隊的經理匯報。兩種情況下，他們都與該經理在同一個範疇（scope）內運作。（例：Dan Na 向國際化平台的經理匯報。）
• 架構師（Architect）：通常向更資深的經理匯報，往往是管理經理的經理。他們常負責跨越該經理職責範圍的一條「橫切面」，例如資料建模。（例：Keavy McMinn 向 CTO 匯報。）
• 解題者（Solver）：通常出現在「弱團隊概念」的公司裡，這類公司的匯報層級往往較不明確或不刻意。最常見是向團隊經理匯報，但你什麼配置都看得到。另一常見模式是把這些人集中進「CTO 辦公室」或「CEO 辦公室」，由一位主管直接指派工作。（例：Ritu Vincent 隸屬於一個向 CEO 匯報的孵化器。）
• 左右手（Right Hand）：向資深領導者匯報，通常是負責上百人的經理，並以該領導者的權威行事。（例：Rick Boone 向基礎設施 VP 匯報；Michelle Bu 向產品長匯報。）

理解這些不同原型典型上如何匯報進組織，有助於解讀匯報結構表面上的隨意性。

CTO 辦公室（Office of the CTO）#

許多人在工作中沒遇過「CTO 辦公室」這個概念，值得補充說明。通常是 CTO（有時 CEO 也會做類似安排）底下有兩到八位 Staff-plus 工程師直接向他匯報。這些人被當作資深領導者對待：拿到一個問題或機會去追，幾乎沒有管理支援，但擁有能在必要時倚靠主管撐腰的近身位置。這類辦公室裡，通常混合了架構師、解題者與左右手。

CTO 辦公室通常出現在公司演進的較晚期，且往往是為了繞過某個難解的既有組織問題而引入——例如 Staff-plus 工程師與管理團隊之間缺乏信任，或 CTO 無法有效授權。

如果你在公司很早期就想動用這個概念，先問問自己：你是不是在迴避一個本該修好的問題？

但實務上……#

根據原型，理論上每位工程師都有一個「正確」的組織位置，但實務上你會發現，鮮少有組織的實際匯報結構能完全對齊那個理論結構。

• 有時是管理團隊對組織結構缺乏關注。
• 有時是缺乏管理頻寬去支援位在正確位置的人——例如「正確」的經理已經在帶一個十二人的團隊，無法再有效支援一位工程師。
• 另一常見情況是結構變動太頻繁，經理不願再次更換工程師的匯報對象，尤其換經理常導致抽象、四平八穩的績效評估。

如果你認為自己向錯的經理匯報，這是可以和經理談的合理話題，但要知道許多經理會對「我不是適合你的經理」這種暗示產生防衛反應。若你的經理夠成熟、你們關係也夠好，就直接談；若不然，比較低風險的做法是和他的隔級主管（skip-level）做一場較抽象的討論，聊聊 Staff-plus 工程師在他們組織裡該向誰匯報。

在急著倡議改變之前，先問自己：如果匯報結構真的改了，你認為會有什麼不同？匯報結構是一種權威，而人們普遍高估了權威能帶來的幫助。

典型的陷阱是：最能從額外權威中受益的人——少數族群與女性——恰恰是其經理最可能對改變提議產生防衛反應的人。

它應該怎麼運作？#

如果你想為管理團隊設計一份提案，說明他們該如何隨時間進行這類組織調整，有幾點值得考量：

• 能立即調整就立即調整。 拖延會迫使當事人經歷兩次轉換，包括在舊、新角色之間那段特別難熬的中間狀態。哪怕代價是接受較少的管理支援（因為新經理工作已滿載），只經歷一次角色轉換總是風險較低的。
• 無法立即調整時，一定要為「調到正確經理」設下時程。 如果沒有一個明確重啟結構的時間點，這件事就相對更不可能發生。

多數公司都難以建立起這種支撐 Staff-plus 工程師作為真正領導者的組織基礎設施，因此請把它視為一個以年為單位持續推進的問題，而非一夜之間就能修好的事。若你抱著「立刻、永久解決」的期待進場，很可能會遇上一段顛簸。