R&R（Roles & Responsibilities，角色與責任）這個詞在公司簡報上看起來像行政流程的東西——在組織圖、JD、OKR 文件裡才會出現。
實際上 R&R 是工程師職場生存的第一道防線。
R&R 沒設好的環境裡，IC 會自動變成「補全所有缺口的人」。短期看是「能者多勞」，長期看是被結構吸光的寄生關係。這篇就是要把 R&R 從「人資文件」拉回到「IC 該主動經營的判斷」。
不健康 R&R 的真實樣子
我親自走過一個案例。一個類 EC 專案，規模沒有很大，但人力超級缺乏。我那段時間在那個專案的 scope 是：
前端、後端、DBA、infra、PM、MIS、人資。
不是我自願擴大 scope。是邊界外沒人接，東西卡住，最後只能我補。久了所有人會習慣這個分工——但這個分工不是健康的「合作」，是一種寄生關係的常態化。
這就是「沒 R&R」最具體的樣子。不是文件上沒寫，是結構上沒人在維護邊界。
更完整的案例跟離開的決策見 AI06 #12。這篇聚焦在判斷依據，不是個案。
為什麼 R&R 重要（不是行政流程）
R&R 不是 HR 文件，是兩件事的根本：
第一：沒 R&R = 補洞的 IC 變成寄生關係宿主。 寄生關係裡被吸的那一方會持續工作但持續無法成長——因為時間都拿去補別人的洞了。
第二：沒 R&R = leadership 把責任 outsource 給 IC。 最常見的 pattern：主管把「教育同事」「改變團隊認知」「統一團隊方法論」這些本該是 leadership 工作的事，丟給強的 IC 去做。
兩個現象是同一個結構問題的兩面。
不健康 R&R 的三個訊號
訊號 1：你的 scope 跟團隊缺口同義
健康的 R&R 是「我做這幾個範圍的事，邊界外有別人」。
不健康的 R&R 是「邊界外沒人接，所以我補」——前端缺人我補前端、infra 沒人我補 infra、PM 沒寫 spec 我補 spec。久了你的 scope 不是被「你的能力」定義，是被「團隊的缺口」定義。
這個是 R&R 失能最早期的訊號。當你發現自己的工作描述用「能補的東西」就講完，而不是用「我負責的領域」講完——這個邊界已經出問題了。
訊號 2：主管把「改變所有人認知」當你的 KPI
這是我親身遇過的對話，主管原話大致是：
「你要告訴我用 AI 以後省了多少時間。資訊部門應該是最靠近 AI 的，所以你們都要用 AI、要統一用法。」
「改變所有人對 X 的認知」這個 ask 本身就有結構性問題。
講了有用的話，每個人都嘛台大、建中、北一女了。
這話聽起來像玩笑，但邏輯是真的——如果說服別人改變認知這件事這麼簡單，這個世界上不會有那麼多教育階級的差異存在。要嘛這個團隊在做直銷（強制信仰一套方法論），要嘛這個 ask 把 IC 當邪教教主（用一套說辭讓所有人放棄原本的判斷），不然「改變所有人認知」這個 KPI 根本是不可達成的。
主管把這個 ask 丟給 IC，反映的不是員工教育問題，而是 leadership 的責任分配出了問題：
「找個強的把弱的拉起來」不是 leadership，是把 leadership 的責任往下委派。
訊號 3：工具/流程採用要你「強制統一」
工具採用本來就是 pull-driven 不是 push-driven。
如果一個工程師覺得 AI / Linter / TDD / Code Review 哪個工具好用，他早就主動用了。不用 IC 去教、不用主管下令、不用全員 workshop。
「強制統一」會有效果的話，每一個團隊老闆隨便講一句大家就照辦了。實際上工程師花十年養成的工作習慣，不是被外部 push 推得動的東西——這是個人認知的修行，是他們十幾二十年累積的習慣、思維、職涯態度。
當主管的指令是「強制團隊統一用 X」，本質上是在問你：用直銷或邪教的方法去 push 一個工具？接這個 ask，等於接受一個失敗的前提。
健康 R&R 是什麼樣
把上面三個訊號反過來看就是答案：
IC 的責任：產出好東西、把判斷講清楚、把問題 raise 給對的人。
主管的責任：team culture 塑造、跨人員教育、push back 不合理的 stakeholder ask、建立讓 IC 能專注產出的環境。
兩者邊界：不互相 outsource。
具體例子：
| 情境 | 健康分工 | 不健康分工 |
|---|---|---|
| 新工具導入 | IC 試用 + 寫 review；主管決定全 team 採用節奏 | IC 被要求「教會所有人」 |
| 同事程式品質低 | IC 提供 PR review + raise 結構問題；主管處理人 | IC 被要求「改變他的習慣」 |
| 跨部門卡 | IC raise 問題；主管 escalate | IC 直接被推去「跨部門協調」 |
怎麼 push back 不合理的 R&R
push back 不是反抗，是把 R&R 重新放回正確的位置。具體話術可以是：
- 「這個 ask 我做不到，原因是 X。我能做的是 Y，要不要先試 Y？」 把不可達成的 ask 換成可達成的 sub-set。
- 「這個結果需要主管層的 push，IC 的 push 沒有結構性的 leverage。」 直接點出責任層級不對。
- 「我可以先做 spike 評估可行性，但完整的 rollout 需要主管定義 scope 跟資源。」 接 ownership 的一小部分，把 scope 收回。
push back 的目標不是逃避責任，是讓主管知道 R&R 的問題在哪。如果 push back 之後主管的回應是「不管，反正你做」——這個訊號比 ask 本身更嚴重，那是 leadership 拒絕承擔自己的部分。
什麼時候 push back 也救不了
push back 是維持邊界的工具，但有 push back 也救不了的情境。
如果你已經在「scope = 團隊缺口」「主管要求改變所有人認知」「強制工具統一」三個訊號齊全的環境，push back 的效用會被結構性失能蓋過——主管沒能力處理你 raise 的問題、沒空間讓 R&R 重整。
這個時候 R&R 不是用 push back 修的，是用「離開」修的。詳見 AI06 #12 的案例跟判斷依據。
反思一句話
R&R 是 IC 主動經營的東西，不是被動接受的環境設定。
- 邊界自己不維護，沒人會幫你維護
- 不合理的 ask 不 push back，會默認變成你的責任
- 結構崩到 push back 都沒用，下一步是離開不是再撐
工程師的工作不是「補完所有沒人做的事」。是「在合理的 scope 裡產出好東西」。差別不在工作量，差別在你的時間有沒有累積成你自己的能力。
寄生關係裡，被吸的那一方就是你。