標準寫完沒人看
最常見的失敗模式：有一份很完整的 engineering standards 文件，但沒有人知道它在哪，或者知道但沒有時間讀，或者讀了但不知道跟日常工作有什麼關係。
根本原因：標準被當成一次性的「寫完就好」作業，沒有嵌入開發流程。
修法：標準要出現在工程師「正在做決定」的時刻——PR template 裡的 checklist、設計評審的問題清單、新人 onboarding 的必讀列表。不在那些時機出現，就等於不存在。
每個 Team 自己定，互不相干
每個 team 有自己的 PR review 標準、自己的測試覆蓋率要求、自己的命名慣例——engineer 跨 team 工作時需要重新學習，cross-team 的 PR 沒有人知道用哪個標準。
這不是說要強制統一所有事情——team 有自治空間是合理的。但有些東西應該有全公司的基準（安全要求、資料處理 policy、incident response 流程），team 可以在基準之上加嚴，但不能低於基準。
修法：區分「公司基線標準」和「team 慣例」。前者要明確說明「為什麼統一」（合規、安全、跨 team 協作），後者 team 自決。
Formal Audit 當 Theater
每季的安全審計、每年的 SOC 2 審計——大量的時間花在「準備審計材料」上，不是花在「真正提升安全性」上。審計通過了，大家鬆一口氣，然後繼續做同樣的事。
訊號：每次審計前兩週特別忙、審計員問的問題和日常工作不相干、審計結果和工程師自己的認知差距很大。
修法：把審計要求轉成日常的自動化檢查（CI/CD 的安全掃描、weekly 的 access review）。審計應該是「讓外部人確認我們的日常實踐沒問題」，不是「為了審計才做一次」。
只有 Pass/Fail，沒有 Severity 分類
Code review checklist 有 30 個項目，每一個都同等重要——結果是 reviewer 放棄認真看，或者每個 PR 都有大量的 comment 但沒有一個真正嚴重。
On-call alert 都設成 P1——結果是 P1 失去意義，on-call 工程師開始 ignore 所有 alert。
修法：每個標準項目要有 severity。Blocker（必須修才能 merge / 上線）、Warning（建議修但不 block）、Info（供參考，可選）。只有 blocker 才消耗人的注意力，warning 和 info 讓人養成好習慣但不製造摩擦。
標準不更新，跟不上技術演進
三年前寫的標準說「用 callbacks 處理 async」，現在團隊全面用 async/await；兩年前說「不用 Docker」，現在全面容器化；一年前說「用 A 框架」，現在 A 框架已經不再維護。
過時的標準有三種結果：工程師默默不遵守、工程師遵守了但用了不適合的工具、新人照做然後被資深工程師說「這個已經過時了」（那為什麼標準還在？）。
修法：每份標準文件有 last_reviewed 日期和 reviewer。每年或重大技術棧轉換時做一次 review。不更新的標準比沒有標準更有害，因為它提供了錯誤的權威感。
標準的最終目的是減少重複的決策和溝通成本——不是讓人填表、不是讓審計員看到文件、不是讓主管有東西可以 KPI。如果一個標準達不到這個目的，值得問它是否應該存在。