心得 | 新任主管與部屬的職場生存術

心得 | 新任主管與部屬的職場生存術
Photo by Nick Fewings / Unsplash

「新任主管與部屬的職場生存術」是君婷老師在商業思維學院主講的講座,講座的主軸有「你是新主管」與「你有新主管」兩個面向,著重在談新任主管在接任前後的各項要點,雖然經歷不多,仍然能對應到之前的一些經歷中,如果當時就有聽到這個講座,或許能更懂得如何應變。

弄清楚升主管的真正原因

那天,主管從大老闆的辦公室出來後沒多久,召喚我進辦公室,邊看著自己的電腦邊對我說:「在團隊還沒有主管前,你先代理,沒有問題吧?」 我:「…應該可以」 主管:「那就這樣,我會發一封信公告」。

在這個情境下,其實可以先緩些回應,問主管改由我代理的原因,從主管的回答思考背後的原因,是因為需要我的專業能力或整合能力呢?或者是期待多複製幾個我?又或者是政治因素?又也許其實只是老闆的明示?先釐清背後的真正原因後,再回饋是否接受。

講座中所謂「多複製幾個我」的概念,主要要傳達的是許多剛開始當主管的人,或多或少會有個迷思:「我 (應該要) 比我的 member 更懂、更專業」,這樣的想法很容易陷入把自己變成團隊天花板的情況,member 也會因此有所依賴,這不是健康的狀況。

新官上任一基礎、三支柱

主要談到了在轉換自己思維的基礎上,對齊老闆想要、建立同儕口碑、改善團隊痛點,聽著這一段也回想起了很短暫的代理工作…

開始接任代理主管後,每天上班主管就召喚我進去指導,在這半小時內聽著主管唸叨著團隊不該重心只放在一個專案、團隊哪個 member 估時程不客觀等等。走出辦公室呼吸一下新鮮空氣,回頭又跟著團隊一起解決問題,打從一開始就陷在「這件事我應該要做」、「那件事我應該參與」的囹圄之中,直到最後黯然退場,收拾包袱離去。

其實這個狀況應該是有解的,既是團隊內部升任的,對團隊的狀況其實也是最清楚的,和同儕的革命情感也穩固,當下我最應該做的是從每日主管的面談指導中了解主管對團隊的期待,試著將這些期待 (或不滿) 轉換成目標,再次地和主管確認,並且開展出具體的工作內容;另一方面則是與團隊 member 面談,讓團隊理解與認同目標,進而執行、改變,用團隊的力量成事,扭轉主管對團隊的印象。

承上、轉換、啟下

講座中有一張印象特別深刻的圖,大意是擔任主管如果能「承上」、「轉換」、「啟下」三者兼具,將能夠朝成為高績效主管邁進,但如果只做到「承上」和「啟下」,等同是個傳聲筒,對不理解卻又不得不做的任務,常常嘆口氣說:「沒辦法,老闆要求的…..」,團隊或許一次兩次會接受,但次數多了也是會無法忍受翻桌的;如果只做到「承上」、「轉換」,基本上是個服務老闆不管團隊的主管,很懂得了解老闆需求,說出一番願景或做出精美的報告,但團隊可能沒有什麼成果;如果只有做到「轉換」、「啟下」,則很容易陷入「我只做我想做的」的狀況,既沒有對齊老闆需求也沒有幫助成員成功,在「我覺得我很辛苦」的苦勞思維中,member 無法得到對應的報酬,也終究會一一離去。

心得

「關係」是需要被好好地處理的,在各自為善時也許不是那麼有感覺,但是在上任一個團隊的主管時、在擔任協作的角色時,如果不重視「關係」,除非夠強大,否則終究要吃一些虧,講座中最多的部分是在引導我們如何去處理好「關係」,前置的準備、事發當下的應對、後續的處理等,不禁想起了一句話:「有關係就沒關係」,只是在這個講座後,我想應該是:「處理好關係,就沒關係」。

回歸到最重要的核心想法,還是轉換自己的思維,當好老闆與團隊之間的翻譯、橋樑,對上理解老闆需求,對下引導成員達成、成就成員,如君婷老師提到的:在擔任主管時所做的事,都應該與「對老闆承諾」、「對團隊承擔」有關。

Read more

桌面上的筆電顯示程式碼,旁邊放著咖啡杯,象徵日常部署與開發工作流

[紀錄] OpenClaw 部署指定模型

上一篇先記了我初試 OpenClaw 的過程,這一輪則是把原本的 docker compose 再往前補一些,順手把預設模型也一起放進去。 這次選擇的是 Ollama,預設模型設成 minimax-m2.5:cloud。 原本以為把 .env 補好、compose 啟動,接著就能開始用了。做了才知道事情沒有我想得順利,仍然還是需要手動進 container 執行指令。 因為這次在 docker compose 想放進預設模型,所以整個配置也跟著多補了一些。原本比較單純的 OpenClaw 部署,後來變成 openclaw + ollama 的配置,讓 OpenClaw 啟動後能直接接上模型。 不過模型名稱先放進去,事情也沒這麼順。 Ollama 要使用 cloud model 得先登入。第一次啟動後,要先進到 Ollama 容器裡跑

By Jo Assistant, Jo
[紀錄] 初試 OpenClaw

[紀錄] 初試 OpenClaw

夯了很久的 OpenClaw,近期開始出現了退安裝潮,我卻正要開始嘗試使用。 前幾天花了一點時間簡易安裝看看傳說中的龍蝦 (OpenClaw) 要怎麼用,略有點覺得值得再往後嘗試時,才開始認真看看安裝方式,在小心為上的前提下,我採用 docker 建置在自己閒置的電腦。 在 docker-compose.yaml 的準備過程,原先只是不斷試錯調整,過了好段時間才有點意識到該好好利用身邊的資源,於是集幾個 AI 模型問答之大成來建置初版,當 OpenClaw 建起來後,又透過跟它的互動,協助我寫一版可整合 Discord 的 Openclaw docker-complase.yaml 自用。(參考) Gateway Token & Pairing 如果沒有特別改設定,當啟動 container 後,透過 http://localhost:16789 會導向登入頁 登入時會遇到 2 個情況

By Jo
Data Platform 筆記#02:從可行到可承接

Data Platform 筆記#02:從可行到可承接

在初版架構逐漸成形後,時間也差不多過了一年。 架構可以跑、資料可以流動,但我仍然不確定它能不能真正落地。這條路必須要團隊可以承接、可以擴展,數據才有機會真正發揮價值。 很慶幸的是,我的主管願意投資時間,讓這個方向能繼續推進。也正是在那段時間,我的思考開始出現轉變... 前一篇的重點,是讓流程從「能跑」走向「能持續」。 而接下來我開始思考:如果這件事要由團隊一起做下去,現在的做法夠不夠讓人接手? 轉變的核心 回頭看那一年,大多數時間其實是在解問題。 但接下來,我該解的是另一個問題:怎麼讓別人不用再解一次同樣的問題? 於是投入了約莫三個月、壓力值很高的一段時間,開始把原本依賴個人經驗與記憶的做法,收斂成可以被團隊理解與複製的形式。 這個收斂,後來具體落在幾個方向上: * 把 Data Center 的部署方式收斂成一致做法,降低環境轉換成本 * 把資料整理作業轉變為配置驅動,讓流程與部署有規則可循 * 整理 DDL 轉換規則與範本,讓團隊能共用同一套方法 * 把知識系統化交付出去 這些事情的唯一核心是 讓方法大於個人。 從個人經驗,到規則明確 第一個改變:

By Jo