三十天終於寫完啦。

雖然今年鐵人賽已經辦到第17屆了，但這是我第一次參加。感想是什麼呢？哇，這真的有硬耶！心中默默對所有參賽過的大大們 respect！

回頭看這些自己寫完的文章，我發現一件事。

這三十天介紹的那些技巧，比如釐清需求、向上管理、跨部門協調這些，其實概念上都不複雜。如果只是要理解這些方法，對工程師來說應該都不難。

但為什麼做起來還是很痛苦？

我自己覺得，可能是因為心理門檻。還有同儕壓力。

理工型的教育，讓我們習慣只看對錯

身為一名工程師，從小到大，許多人習慣的世界是黑白分明的。

程式碼要嘛run得過、要嘛run不過。新寫的演算法效能改善多少，測資放下去跑結果不會騙人。考試答案要嘛對、要嘛錯。一翻兩瞪眼。

但其實我們心裡都知道，職場不是這樣運作的。

所以你可能會發現，這系列文章的前半部，我花最多篇幅在處理的，其實不是知識點本身，而是阿偉的心魔。比如這些軟技能，應該在工程師的職場圈子裡被定位為雜活或髒活嗎？以及來自同事之間的眼光該怎麼辦…之類的。

一直到中後段，當阿偉在心理上慢慢能接受、且開始試著用工程師邏輯來理解這些事情之後，我才逐漸加重知識密度，開始討論更具體的方法和框架。

直到我寫到 Day 25 時，我讓阿偉第一次當決策者，要在小林和小姜的技術路線之爭中做選擇。

那時候阿偉的反應很慌，對於自己「要開始做那些『不完美』的決定了」這件事，感到難以接受。

我寫到這裡的時候，自己也卡住了。

因為我突然意識到，如果我只是教阿偉「怎麼做決策」，那這篇文章跟直接看管理書又有什麼差別？阿偉真正痛苦的，其實主要還是他自己心裡那一關，也就是他覺得自己要開始妥協了。

那時候我就想，對，這才是重點。

這種心理門檻，比學任何技巧都難跨過去。而且這個門檻，一定不只阿偉有。

為什麼我要寫那麼多阿偉的掙扎

有人可能會問：啊你幹嘛要寫那麼多阿偉在那邊糾結？直接教方法不就好了嗎？

因為如果是這樣，那讀到這些文章的人很可能只會覺得：「喔好我知道了」，然後關掉頁面，結果什麼都沒有改變。

但如果我能設法寫出阿偉的掙扎，比如他怎麼抗拒、怎麼焦慮、怎麼擔心自己會變成討厭的人… 然後慢慢找到一個不違背自己底層邏輯的方式去做這些事，這樣有類似困擾的人讀了，才有可能真的跨過那個心理門檻吧。

我覺得，這可能就是為什麼我很想把這些，看起來像是在寫廢話的過程，給寫出來的原因。

因為只有當真的理解為什麼這些技能是必要的、如何用熟悉的邏輯去理解它們，我們才不會覺得自己是在妥協、在背叛自己的專業。

Day 29 寫完的時候，我猶豫了很久要不要讓阿偉明確選技術路線或管理路線。但想了想，還是保留個開放的結局好了。

所以我讓阿偉說：他還在試、還在看數據、還不確定。他依然會焦慮，依然會懷念那些可以整天寫 code 的日子。但他至少能開始，把自己從「非黑即白」的框架裡給拉出來。

我不想讓大家只能逼自己「看開點」

Day 7 的時候，阿偉很抗拒向上管理。他覺得那是「拍馬屁」或是「搞政治」。

這不只是阿偉的問題，我身邊太多工程師朋友都這樣想。而且社會上確實有一堆人會鼓吹：「欸你要學會跟主管相處啦」「職場就是要合群啊」「不要那麼堅持嘛」。

但這些話聽起來就很像在要求我們：放棄你的原則，妥協就對了。

我最討厭這些說法了。這不是我想說的。

所以我想透過阿偉表達的是，其實向上管理不是拍馬屁，而是一種翻譯。當我們能夠把技術貢獻翻譯成主管和其他人也能懂的東西，我們就沒有必要放棄自己的專業，而且還能確保自己的專業價值能被看見、被理解。

我希望可以讓讀到這裡的朋友們，能夠不被「看開點」這種和稀泥論調綁架。我們可以反過來，有信心地告訴來人，我們這是有理有據的風險控制。

除此之外，我們也在 Day 18 裡意識到，有些事情確實超出了我們作為普通職員的能力範圍。但我們不需要用「這就是人生，沒辦法」這種消極的理由來逼自己接受。

相反地，我們可以理性地比較問題的範圍與自己能做到的範圍，算出兩者之間的差距，從而判斷出哪些部分確實不在我們的掌控之中。

你發現了嗎？有了判斷依據後，當我們需要承認自己的影響範圍有限時，就一點也不丟臉了。因為，這只是 diff 出來的結果而已嘛。

類似的邏輯也適用在其他地方。比如 Day 25 的決策的重點不是要不要妥協，而是可量化的權衡取捨(trade-off)。而 Day 28 的跨部門協調不是什麼搞政治，而是基於當責的精神，把問題轉介給有相應權限的人處理…等等。

我想試著把每一個看起來「很軟」的技能，都盡量從工程師所熟悉的視角與邏輯來解釋。目的是希望大家不需要強迫自己放棄我們引以為傲的底層思考邏輯，這反而應該是我們的優勢才對。只要用得好，它也能解決職場上關於coding本身以外的各種問題。

一些小花絮

其實這三十天寫下來，我自己也學到不少。

比如說，我本來以為阿偉會是一個比較扁平的角色，就是「技術很強但不會溝通」這樣。結果寫著寫著，我發現他竟然越來越立體了。他會焦慮、會自我懷疑、會掙扎、會在咖啡廳裡突然鬆一口氣。

我在寫的時候，經常會需要去想辦法揣摩阿偉的心思，比如「他在這種情況下會怎麼反應？」之類的。然後有時候寫一寫就會發現，欸不對耶，他好像不會這樣做耶。然後我就得重寫…XD。

還有設定時間軸這件事情也滿有趣的。我在故事架構裡的設定，是希望讓阿偉在 Day 5 被小陳升遷給打擊到，然後在半年後讓已經獲得某些成長的阿偉，可以有機會能跟老楊重新溝通到他的職涯規劃。結果寫到大概第十天吧才發現自己忘了這件事，好險後來有想起來，成功讓他趕上 Day 24 的主管面談。

喔對了，還有小林、小姜這兩個角色。我本來沒打算讓他們有太多戲份，就是配角而已吧。結果寫到後面，我發現他們在後期其實也滿重要的。有了小林跟小姜之間的思想碰撞，也可以用來寫阿偉必須學會處理不同個性的人這樣的橋段。

不過職場不就是這樣嗎，我們有時就是會遇到各式各樣的人，沒有標準公式可以套用，對吧？

寫給看到這裡的你

如果你看完這三十天了，真心謝謝。

我不知道阿偉的故事有沒有讓你產生共鳴。但我想說的是：

我們其實可以利用自己本來就會的工程師邏輯，像是拆解問題、找 root cause、設計解決方案、控制風險…這樣的視角，來理解和處理這些看似「很軟的東西」。

變數變多了，問題的範圍變大了，但我們依然可以是當初那個，單純喜歡寫code的自己，沒有變。