管理者即 IC

資料來源#

• Running an AI-native engineering org

摘要#

Fiona Fung 在 Claude Code 上一個「spicy」的組織改造：每位 manager 都先從 IC 做起，並持續直接負責產品的一部分。組織維持「agile and as flat as possible」。讓這件事如今變得可行的，是 agentic coding 讓 onboarding cost 大幅崩塌——過去這個成本讓 manager 重新進入 codebase 顯得令人卻步——所以 manager 能在沒有痛苦 ramp 的情況下，重新奪回 maker hours。

這項改變#

當 Fung 加入 Claude Code 時，她最先做的事情之一，就是和 recruiting 合作，讓每位 manager 在承擔 people-support 責任之前都先從 IC 開始。理由是：這能讓 manager 在扛起支援他人的責任之前，先「roll up your sleeves, get into the codebase, and learn what it's like to be an engineer on the team」。她把 flat-org 加上 managers-with-IC-ownership，視為她優先推動且「worked really well」的三件事之一。

為什麼是現在：onboarding 不再令人卻步#

Fung 在她的職涯中（Meta、Microsoft、Anthropic）不斷在 manager 與 IC 角色之間切換，而每次回到 IC 工作時總會感到「a slight hesitation」——「it could be daunting if you haven't done it in a while.」Agentic coding 消除了那道摩擦：onboarding 到 Claude 是「such a different experience」，因為她可以請 Claude 教她 surface area，而不必占用工程師的時間（Code as Source of Truth）。那個歷來把 manager 推離 codebase 的成本——ramp time，以及開口求助的 social cost——大幅下降了。

Dogfooding 的理由#

更深層的理由是 dogfooding（見 Dogfooding as Product Discipline）：「on Claude Code we use Claude to build Claude, and Claude Code to build Claude Code」——所以一個不在 codebase 裡的 manager，等於沒有在親身體驗他們正在出貨的產品。Managers-as-ICs 正是 leadership 持續「feeling the product in their bones」的方式。它是在 management layer 上對 dogfooding norm 的結構性強制執行。

與 engineer–PM convergence 的關聯#

這是 Engineer PM Convergence 在 management layer 上的實例：Boris Cherny 指出 Claude Code 團隊的每一位成員都寫程式（EM、PM、designers、data scientist、finance、user researcher）。Managers-as-ICs 把「everyone codes」沿著 org chart 向上延伸，並且和 Anthropic 所採行、更輕量、更扁平的 AI Native Product Cadence 一致。

相關連結#

• Fiona Fung — 推動了這項改變
• Code as Source of Truth — 把 Claude 當作 onboarding doc，正是讓 manager 重新成為 IC 的代價變低的原因
• Dogfooding as Product Discipline — 理由所在：manager 必須使用／打造產品，才能維持 product sense
• Engineer PM Convergence — managers-as-ICs 就是把「everyone codes」沿著 org chart 向上延伸
• AI Native Product Cadence — 這種組織形態所支撐、更扁平更快速的組織
• Boris Cherny — 這項管理規範所指向的 IC 原型（單日可累積 150 個 PR）
• Harness Shrinkage as Models Improve — 不斷下降的 onboarding／coding 成本，正是讓更扁平的組織變得負擔得起的原因
• Compounding Loop Optimization — 「build your own tooling」預設了人人都會寫程式；這個扁平、IC 密集的組織，正是讓「一個下午就做出來的內部工具」成為常態的基底

開放問題#

• Fung 自己的開放問題：「Do you still need separate iOS and Android orgs?」——如果工程師能透過 Claude 跨平台靈活切換，傳統上按平台拆分的組織或許也會瓦解。扁平化究竟能走多遠？
• manager-as-IC 在組織超過某個規模後還能 scale 嗎，還是只在 Claude Code 還小、codebase 仍然 Claude-legible 時才行得通？

資料來源#

• Running an AI-native engineering org