我自己是從RD出身的主管，我自己也想了很久，我到底做對了什麼，與可能做錯了什麼，讓我自己培養出這樣的一個團隊。不斷思考這個問題，除了深怕自己犯錯毀了一個團隊外，也在尋找蛛絲馬跡，試圖找到還不錯的成功因子，把經驗複製到別的地方，擴張影響力。

其中我覺得有一塊很有趣的互動，是來自於我與現在技術主力團隊的工作界線與分工。

我剛開始的團隊夥伴中，有一個不務正業的阿宅，資訊不是他的本行，可是在新東西的學習與運用上，有他很獨到的能力，讓他能快速駕馭這些東西進行嘗試。剛開始跟他一起合作，是改版內部websocket服務，他負責核心的技術開發，我跟他設定使用情境，管理方式，等到專案到一階段後，我負責對外取得資源測試，他負責數據蒐集。

我們最常混戰的地方，就是爭論某些業務邏輯到底該放在服務內，或者應該是由呼叫端額外自己開發業務邏輯，服務應該維持乾淨。我的思考點是某些邏輯核心完成，使用起來就會比較便利；他的邏輯這些業務邏輯並非每個專案都不變，則這個工具就變成此專案的專屬工具，無法通用。但即便對於業務邏輯的置入有衝突的激辯，但我們卻能把問題進一步的抽象化轉換成工具層面的方式，仍可對對應的業務邏輯做出便利的使用方式。

後來我自己已經在思考轉型為專職的管理人，除了自己發現coding的天花板已經到了以外，我覺得整個團隊人才濟濟，不缺coding的肝，但缺少組織規劃的腦。剛好我們後續又一起合作帶領團隊進行一個在GCP上的產品開發。

這個時候我仍負責專案面的進度規劃，切細功能，成為前後端溝通的橋樑，但是會學著"退一步"，引導同仁在專案過程中，多一點思考商業目標，與演練如何透過驗收Demo縮減雙方的認知落差。

這個時候面對後端的工程師團隊，我一直給團隊一個觀念：反正到時候出問題的時候是你們要上來收尾，我不會強制你們要用我的方法，但是團隊必須要最小滿足我提出的管理議題。而我在意的管理議題就不外乎：log寫清楚、維護人力便利度、壓力測試、內部白帽駭客執行等等而在面對前端工程師團隊的時候，大概只比較在意商業目標上如何追蹤，以及是否有過多的特例處理等。

不同於有一些技術背景轉往管理職後，死命監管每一個技術細節，我自己選擇成為工程師的保護傘，由工程師團隊負責"現在"的專案功能，我幫團隊思考"未來"上線營運該注意的事情。當他們把當下的進度完成後，我對商業需求的狀況想像，幫他們減少重複修改或者新增功能的工作。兩個不同角色的團隊，各司其職，發揮所長，或許也因為是這樣讓我們團隊仍快樂的工作中吧。

「弟兄姊妹和睦相處是多麼幸福，多麼快樂！」 (聖經詩篇133:1)