我的本週第二篇文章。我本來應該一週只寫一次，不過算了啦，這篇草稿我已經放了一陣子，直接進主題吧。
關於「ownership mindset（主人翁心態）」有一件事，管理層的人沒人想承認：你們喜歡這句口號，卻討厭它帶來的行為。
你想要的是會在乎的工程師。會思考擴充性的人。會問「等等，這四個月後會不會炸掉？」的人。會把產品當成自己在做的人。
很好。然後某個人真的在會議裡這麼做了，接著他們就突然變成了「很難搞」、「不是團隊合作型的人」、「太負面」，或者我個人最喜歡的那句——「你就照我說的做不行嗎？」
這齣戲我看過太多次，台詞都快能背了。
劇本
經理 / PM / 現在戴著「決策者」帽子的任何人：
這件事我們需要一個真的有 ownership 的人。要在乎產品是不是真的能運作。
某個人提出了架構上的真實疑慮。不是感覺，不是氣氛。是限制條件、資料模型、失敗模式。是那種之後會讓人半夜驚醒的東西。
同一個人，90 秒後：
你幹嘛這麼強烈反對？為什麼這麼難配合？我們已經落後了，先上線再說。
所以到底是怎樣？
你要的是 ownership，他們也給了你 ownership。現在你又在生氣，因為 ownership 連意見也一起帶來了。
你不是搞不清楚，你只是覺得這樣比較方便
我以前以為這是溝通問題。不是。是誘因的問題。
你今天感受到的是延遲，不是之後的事故。 設計上的反對意見會拖慢你想要在這個 sprint 內推出的東西。它阻止掉的爛攤子會在下個季度、在別人的 KPI 下面才浮現。你當然會優化眼前這個房間裡的痛點。
階層結構在你站在上面時，會讓你覺得很有效率。 一個資深決策被質疑時，感覺不像工程討論，反而像不尊重。就算那個問題是「這樣在並發寫入下會把資料弄壞」。你要的是答應；你拿到的是理由。這兩件事對自尊來說感受完全不同。
服從會讓人覺得事情在進展。 工程師說「好，我來做」會讓你有種事情在推進的爽感。工程師說「我們應該重新想一下資料模型」就像在拖慢進度。你大腦懶得算：少摩擦 = 好領導。不是。少摩擦 = 更安靜的失敗。
而且「ownership」這個詞，對不同人來說意思根本不同。 你說的時候，通常是指「確保它上線，別來煩我」。我聽到的意思是「確保它不要害我們出事」。這兩者會衝突。你卻一直用同一個字，好像那是我的問題。
安靜的工程師，根本沒有在 ownership
這段可能比你想像中更讓人火大：那種每次都照你要求做、永遠笑臉迎人、從不反抗的工程師，並沒有展現 ownership。
他們是在優化被認可。
他們是在降低衝突。
他們是在服從命令。
這些都不是 ownership。這只是責任轉移而已。
等出問題時，他們有完美台詞：「我就是照規格做的。」乾淨的手，分散掉的責任。你拿到的是你自己獎勵出來的服從型執行者。
那個說「這樣之後會出事」的人，才是真正在把結果當成自己事情的人。他們是在一個通常會懲罰這種發言的會議裡，拿社交資本出來冒險。你如果懲罰他們，不要假裝驚訝為什麼接下來三個人都學會閉嘴。
從我們這邊看，真正的 ownership 長什麼樣子
不是在設計審查裡當個難搞的人。是這些：
疑慮提早講。 在設計階段就講，不要拖到實作三週後，才發現要改方向會浪費一個 sprint，還會傷感情。
講理由，不講感覺。 「這個 N+1 在我們目前的成長曲線下，1 萬用戶就會掛」比「這感覺怪怪的」有力多了。如果工程師說不出失敗模式，就該反問。如果說得出來——就聽。
提出替代方案，不只是說不。 「如果改成用 user_id 建索引呢？」這才是 ownership。「這樣不會成功，祝你好運」只是表演。
知道什麼時候該升級處理，什麼時候該先做再學。 有時候你確實得先把不完美的東西上線來學習。有時候你是正往一個已知的地雷走去。一個好的 owner 知道現在開的是哪一種會議。
對結果負責到底。 「我早就說過了」不是 ownership。真正負責是：如果你錯了，你會幫忙善後；如果你對了卻沒人聽，你還是會幫忙善後——而且你會記得是誰沒聽你的。
當你把這些特質訓練掉，最後會得到什麼
我看過這種文化慢慢定型。它一點都不隱晦。
- 工程師開始優化「不要被怪罪」，而不是「做出能長久的東西」
- 技術債在沉默中累積，因為發聲會影響職涯
- 聰明的人默默更新 LinkedIn
- 明明早有徵兆的失控，卻還是讓管理層驚訝
- 「團隊合作」變成了「不要質疑錯誤決策」的暗號
你買到的是短期速度，付出的是中期混亂。然後你排了一場回顧會，大家一致同意「應該要更早說出來」，卻沒有人問：那他們為什麼後來不說了？
如果你真的想要這個
不要把 ownership 當成一種人格特質來要求。要建立出可以安全展現它的條件。
把設計討論跟實作討論分開。 讓大家先自由地思考這東西到底可不可行，再談 commit 到 sprint 的事。認真思考和快速交付不是敵人，把它們硬塞進同一個會議才是。
獎勵你嘴上說想要的反對意見。 如果有人提出合理疑慮，而你最後還是推翻了他們，那就把它當成一個 公開的決策。不要假裝那段討論沒發生。如果之後證明他們是對的，就公開承認。當著大家的面說。如果他們錯了，他們會學到這個領域。無論如何，訊號都應該是：講出來就是工作的一部分。
講清楚。 「請負起責任」這句話沒有用。你是指「就算做得很糙也要禮拜五前上線」嗎？那就直接說。你是指「這東西必須撐得住 10 倍流量」嗎？那就直接說。模糊的口號只會讓大家猜哪種做法最不容易被罵。
當我們提出反對意見時，請真的聽。 不是因為我們永遠是對的——不是。我們是因為天天待在你只透過工單看到的 codebase 裡。那不是態度問題，那就是你雇用我們做的工作。
把分歧正常化。 我待過最好的團隊，大家都會為設計爭論，但隔天早上還是彼此信任。分歧不是針對個人。把它個人化，最後只會養出應聲蟲和壞掉的系統。
結論
你大概是真的想要有 ownership mindset 的工程師。
但你不想要的、而且一直不小心篩選出來的，是那種會笑、會照做、然後眼睜睜看你撞牆、自己只求維持人緣的工程師。
ownership 很煩。它會問很不方便的問題。它會拖慢那種「先上線再說」的會議。它會逼資深主管為自己原本想當成定案的決策辯護。
如果這聽起來很累，太好了。這就是做出不會在真實使用者碰到第一下就垮掉的產品，所必須付出的成本。
你不可能同時擁有「真的在乎的人」和「從不反對的人」。只能選一個。
如果你選的是服從，那至少別再叫它 ownership。這個詞對我們其他人來說，還是有意義的。
原文出處：https://dev.to/adamthedeveloper/stop-saying-you-want-ownership-mindset-34nf
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
