軟人手札

人生難得清閒，終於有空把一直想上的樹呆子—修剪的科學與應用上完了。他們的YT頻道中也有許多相關內容可以參考，例如下面這段就有涵蓋一些重點，值得一看：

會想上這門課，主要是因為好奇吧。好奇為什麼我修剪的成功率這麼低？為什麼我按照一些園藝書籍、網路上的教學，甚至農園一天到晚豐收的長輩的指示去修剪，僅有極少數的菁英會「似乎」長得不錯，大多數都是愈來愈衰弱乃至死亡？好奇為什麼好好的路樹總是被鬼剃頭？為何台灣的景觀工程總是對樹木如此粗暴？樹木在自然環境中自己就可以長得很好，為何會有一定要修剪才會長得好一說？難道有某些樹種已經被馴化，生長模式上就已經配合人為介入？

總結來說，我和大多數人都一樣，認為修剪是只是一種「美容」，跟剪頭髮差不多意思，殊不知這應是奠基在對樹木生理有足夠的理解下進行的外科手術，其實更接近截肢。因此我過去所學過的矮剪、短剪、疏剪等，其實常是錯誤地以預設的輪廓來裁剪超出範圍的枝條；又或者誤以為當樹勢衰弱時，透過修剪來「減輕負擔」是一種補救。這些做法回頭看來都是偏差，偶爾出現菁英，只是運氣好罷了。不當的修剪會催生許多不良枝條，但知識不足加上短視近利下，鬼剃頭式、齊頭式等暴力修剪自然就成了主流——因為立刻能從大量催生的枝條看到效果，樹體本來健康的話也能撐個好幾年不出問題，誰還要去管十年二十年後的事情呢？

兩千塊就能吸收到將複雜的樹木生理與實務應用濃縮成像我這種園藝菜雞也能理解入門的教材，真的是物超所值。課後，當我再次拿起剪定鋏到前院，我仔細觀察那些孩子們，發現自己更能理解他們的形體為什麼是長成那樣，也只做了最基本的清理修剪。走在公園裡，似乎更難忽視路樹身上無數的人為傷害了，也不知是不是好事。

時光匆匆，去年年初在慕尼黑購入的咕咕鐘已經使用一年多一點點了。回想起來，Max Krug的店員真的耐心驚人，竟然願意陪著我一個一個轉，當時網路還不知怎地不穩，無法視訊只能一個一個錄影慢慢傳慢慢討論，期間我至少聽到兩次有人說「不，你不可以買咕咕鐘，絕對不可能」，而且還是中英文皆有。在店員不離不棄超過一小時的陪伴下，我們終於買下了上面錄影中的這顆，買完也快關店了，包含國際運費，估計是當晚最大的一筆生意。

先說結論，除非對這樣純機械、純手工的藝品特特特特特別有愛，千萬別買。

在實際使用過前，我在診所、餐廳、甚至家具店都看過牆上有鏈條發黑積灰塵的咕咕鐘，很納悶這東西也不便宜為什麼就任它在那邊凋零，實際經歷過後可謂徹頭徹尾地懂了。

這是個天氣翻得比翻書還快的奇怪春天。正當我一邊嘴裡碎念著到底要冷到什麼時候，一邊走到陽台時，赫然發現我完全放生不管、莖部已經完全木質化的大理花居然大大地盛開了。品種我已經忘了，但它開的正是去年在花市買進時黃中帶著一抹紅，彷彿陽光以球狀輻射開來的大朵黃花。

大理花其實很好養活又很好繁殖，但要種得漂亮完全是另一回事了，我總是不得其道，過去種過的隔年都長得又弱又小。因此這次索性不特別養了，新年買了兩盆，花期過了後就隨便丟在陽台，連盆土更換都懶，就只有一次夏天大雨把培養土沖掉太多不好看才隨手丟了些土進去補；其中一盆在秋老虎肆虐時死去，剩下一盆幾乎全株乾枯，只剩下一根木質化的側芽勉力撐著，我把乾掉的地方剪除後也不再理，沒想到竟令我大為驚嘆。

太座大人常調侃我說，「你特別顧的都嬌貴到活不了，放養的永遠都最旺」，我拉著她去看，她嫌外面風冷，看一眼便縮回房裡，不忘補上一句：「你現在最好也不要去管它。」聽某話，大富貴。除了加條綁帶讓它不會被自己的重量折斷外，我就這麼不管。

結果隔一週它又開了一朵紅花。

寫這篇文章的當下它還有三個大花苞在準備。這種大花的品種在花市買入的時候通常能開兩到三朵大花就偷笑了，沒想到它今年除了展現異色來在品質上超脫，還準備在數量上也超越自己。欣賞之餘，也讓我重新思考在成長的過程中，看顧者所扮演的角色究竟是什麼。

只要每次macOS更新，我那愈陳愈香的工作環境一定會以autojmp為首開始噴上面這個錯誤，這只是因為xcode command line tools在某個版本起似乎就不再內含python這個symlink了，但一旦呼叫到python，它又莫名會提示要安裝命令列開發工具，裝下去還是不會有，跑了python再提示，裝了當然還是沒有 …

雖然autojmp在2年前就已經併入了一個預設為python 3的PR，但在我的系統上還是會報這個錯。因此每次我都只好摸摸鼻子做一個symlink給它：

XCODE_BIN_PATH="$(xcode-select -p)/usr/bin" sh -c 'sudo ln -s $XCODE_BIN_PATH/python3 $XCODE_BIN_PATH/python'

當然，用這個方法的前提是系統裡已經沒有在用python2的東西了。想想應該改用homebrew的版本就會好，只是xcode command line tools目前沒辦法選擇不要裝python，我個人又不喜歡系統裡有裝多個同樣的東西，只好暫時再忍受一陣子它的小脾氣。

說起來我周遭從來沒有其他人碰過這個問題，看來不只是鄰居小孩的身高會把人催老，連工作環境的差異也會 🫖

近日我們團隊迎來新人J君加入，我們聊到在a8c當團隊領導者的經驗，話題逐步延伸之下，不知不覺間聊到領導風格一事。

上面這張圖引用自Agile42的Archetypes: mapping organization, culture and leadership一文 — 不過是很久很久以前的版本，現在他們早已換成另一張很像投影片的圖，我很慶幸當初有把這張存下來，手繪風萬歲！

我常常在和別人討論領導風格議題時拿出這張圖來，因為它很簡明地透過關係圖表達出五種常見的團隊架構。就像軟體設計上一樣，不同的範式都是因應不同的情境而生，重點在於如何鑑別出情境並找出最佳解。團隊的運作也一樣不應天真地認定有涵蓋一切的解方，而是要因應團隊成員、現下情境、以及領導者本身的組成來決定，因此我在引用這張圖時會把這解釋成「領導風格」而非比較硬性的團隊結構，並且視情況轉換風格。舉例來說，在文化開放的科技公司Strategic(agile)模式可以運作得不錯，但把它用在傳統製造業的產線上恐怕是一場災難。

因此，在實務上大概可以分為幾個部分：

1. 建立自覺：明確意識到你「預設」的風格為何，適合的人事情境為何。
2. 刻意訓練：刻意學習了解其他風格，它們的適用情境，並加入應用。通常在建立足夠的自覺後你會開始感覺到自己的第二風格是什麼，可以從它開始嘗試。
3. 深入自覺：深化自己擅長的風格，並深入了解自己不擅長的風格以及原因。觀察學習其他領導者會相當有效。

以我自己來說，我的預設領導風格是co-ordinator；而在應對時程緊迫的C-level專案或辦團隊活動時我會轉到expert(順帶一提，這兩種expert風格意義蠻不同的，前者是為了時效，後者是為了讓大家不用分心在雜務上)；有時候團隊被拆分到數個，我會刻意不參與專案細節，轉換到coaching。而我指派團隊中的A君去帶Built By WordPress.com Express專案時他展現了令我驚豔的peer風格(這是我最不擅長的風格)，D君在帶新版方案表格專案時則展現出雷厲風行的expert風格，我有幸見證他們的成長，也有幸成為幫他們點出來的人。

總之，了解自己總是成長的第一步，這在領導管理上更是真切。