我的前公司，雖然在PTT的評價並不好，但我仍然可以公正地說：他是我20年的職涯以來，親身經歷過最好的公司管理制度。(但顯然我前同事都不這麼認為)
技術方面：
Code Review: 在merge到main之前，要經過languange commitee的code review, 需要至少一個approval才能進。對於提交PR的人影響是讓自己看到程式架構上的盲點，code裡行間的一點鬆懈之意都可能會被揪出來公諸於世。
Unit test coverage & code quality: 在提交PR之前，一定要過unit test coverage跟code quality這兩關，沒過的話連code review機會都沒有。
績效考核方面：
Peer Review: 匿名評論，用他人的角度客觀地了解自己的優點與缺點。很殘忍，但個人進步的第一步是發現問題。給了自己進步的目標。每個人在平時都要在自己的工作職責內做好服務，每一個跟你合作的人都是自己的client，每次跟他人有合作機會，都要控制好自己的EQ，儘量多做好服務，提供好的建議，在自己份上多做一步，這些微小的舉動都會讓你在每半年的Peer Review獲得好評。
Performance Review: 半年一次。先寫自評 => 再參考Peer Review =>再來team內做ranking => 然後加入不同team的越來越多人一起sorting，最後每個人會得到一個A+, A, A-, B, C等符合常態分佈的分數。然後這個分數會跟你最終拿的bonus有正相關。所以對個人來說是超級大事。如果不幸得到grade C，就可能會離開這個公司。自評面向包括Product Impact, Technical Excellence, Mission Mentality，每一大項都有很明確的定義，不是抒情文。你要提出足夠的事實跟數據來證明你在以上這幾個方面有做出貢獻，如果你稍微誇大，在ranking meeting裡manager也很容易可以把你揪出來。
這2個制度的好處是：讓同事之間有競爭(grading)、也有合作(Peer Review)。必須要保持自己在組織中前20%優秀，如果落後了，ranking結果會告訴你，你在下一個半年就要比其他人更努力地趕上來。
專案Review方面：
EOM (End Of Milestone) Monthly Review: 每個project每個月會舉行一次，最大的老闆會參加，由PO來做報告。報告的內容，除了要列出what went well之外，也要講出what’s not on track，不能報喜不報憂。老闆會針對每次的EOM提出一些他認為下個月應該要進步的地方。老闆情緒表達很直接，進展很好就會大力稱讚，如果project看起來沒什麼希望，可能當場就會砍掉，直接團滅。每個月每個project都必須死命地往前突破，不能停在某個地方，或是突然轉換題目，在EOM裡很容易會被發現，被嗆到爆。
量化指標：我們用Monthly Active Request來量化每個project的user喜愛程度。每個MAR的定義也是都要經過老闆approve，不能說user按一個鈕發3個API就算3個request，這一定會被打槍。而是要從end user角度來計算MAR，例如他登入後，必須要在頁面停幾秒才算一個MAR，那也不是每個user activity都算數，要有意義的action才算，用這個數據來量化這個service的被使用程度。每個PO再也不能空口說白話說自己的服務user很多、大家都很喜歡用。每個月Review MAR的數字，成長趨勢就很容易看得出哪個project猛烈成長，哪個停滯不前。
服務品質方面：
On-call system：每個online service都需要訂自己的SLA，例如response time P95 200ms以上就是sev3, 300ms 以上是sev2, 500ms以上是sev1. 而sev2以上就會馬上打電話給排班的人，也同步會create一個issue，需要即時處理。而每週也都有meeting會去review每個service的quality (sev count, availability, reliability)。常出包的service會被highlight，自己就要想辦法減少sev1, sev2出現的次數。這是認真要做online service所要展現出來的態度，排班的人半夜接到電話也要爬起來修。我們的user雖然不多，但都很重要。我們自己要在客戶發現問題之前就要修好，不能等對方發現了才用line來抱怨，這樣都太慢了。在Amazon有一個不成文規定，就算是在高速公路開車中接到service alert call，也要pull over到旁邊趕快修，就是要做到這種程度。
Release Process: 我們要release到production環境之前需要提供非常多資訊，例如最基本的repo/branch/commit，stress test result，SLA definition，call chain，test plan and report，code quality，UI and usability report，End to End test，MAU/MAR definition。然後每一關都有相關人要approval，Devops才能上到Stage，測試過後，再deploy到production。如果出問題了，也不能輕易地上production改，需要再上一張Hotfix Request ticket，當然不需要跑全套，但也要某部分的approval才能更新。很多時候Engineer會自己Hotfix或是release到production而PO不知道，可能沒有經過嚴謹的測試跟review就上去，導致user無法使用。或是根本沒有需要做這次的release。這個流程很大部份是為了因應ISO27001，但這樣的制度也讓每次release的目的被記錄下來，該被inform的人都知道這件事，雖然麻煩但仍利大於弊。
組織管理方面：
All Hands: 每兩週的週五(通常)會有一次全員大會，由大老闆簡單present一下每個project的進展，讓所有人都了解大致的business情況。也會開放匿名問題，老闆會當場一一回答，這也是展現公司文化的大好時機。例如表揚某員工的mission mentality，鼓勵大家work/life balance，以家庭為重，或是如何處理實際問題，例如我們常說要尊重每個engineer的喜好，但如果有一件必要的事但是沒有人願意做，這時manager該如何處置。All Hands比較像是大內宣的時間，搭配上吃吃喝喝，比較輕鬆的氣氛，個人覺得QA環節非常有意義，可以觀察組織文化被現實挑戰時，文化是否依然是贏家。
定期1–1：大老闆每一季會跟每個員工排一次1–1，EM也需要每個月跟自己的team member排一次1–1。在1–1會比較輕鬆地進行，不會在裡面交代工作的目標或進度。比較多是關心個人的狀況：例如工作生活有沒有遇到問題，對於組織、管理有沒有想法，有什麼建議等。我覺得這是建立彼此信任關係很好的管道。信任關係是不能速成的，依據我的經驗，大概到第3次，當你的member確定你會認真傾聽他的回饋之後，他才會說得更多。這也很適合告訴你的member他做得好的部分、可以努力的方向、以及你會對他在公司的職涯做什麼樣的規劃。
總結
仔細看的話會發現上面很多會議都是Routine進行，而非Event-Driven。也許有人會覺得會議過多，但這跟主持人組織的功力有很大關係，如果每個會議所有參與人都覺得很有收穫，獲得很棒的建議，跟清楚的方向，相信頻繁的溝通就會省掉很多走歪路的時間。
大部分的公司都是Event-Driven的會議，為了處理緊急狀況、救火。再厲害的人如果長時間處在救火模式，他也在公司待不久的。
