三階段、四方法,有效的部屬指導原則

三階段、四方法,有效的部屬指導原則

不久前,有個剛升任主管的朋友找我聊關於部門帶領的問題,他劈頭的第一句就說:「唉,我覺得我帶的這幾個人不太聰明,實在有點無力。」

Gipi:「怎麼說?」

他:「我給他們充分的信任,幫他們安排好工作後,要他們自己抓時程,並自己掌握時程,有問題的時候才回報給我,結果呢?每件工作都 delay,然後我就一一用問問題的方式引導他們思考,他們還是不知道問題在哪。」

Gipi:「嗯,會不會是方法用錯了?」

他:「不會吧,我看很多文章、書或者前輩的分享都是用這樣的作法,你不是也很 prefer 讓團隊成員自己有 ownership,自己把工作得責任擔起來,不是也說要用問問題跟引導的方式協助部屬成長嗎?」

Gipi:「我是有這麼說過,但你文章是不是都只看一半啊?」

他:「什麼意思?」

gipi:「培養 ownership 不是不管他,你的做法是放任而不是信任,因為你沒有確認過每個人的基礎能力與對工作的熟悉度到哪了,有時他們還需要協助,但你卻期待他們可以自己搞定所有事。這跟聰明與否不見得直接有關。就跟當你還不知道吃飯要用筷子,或者還沒學會怎麼用筷子前,你只知道用手、湯匙跟叉子來取用食物,你的成員可能就是處於這樣的狀態,他們的知識、經驗、能力都還不足以獨當一面,而你卻期待他們自己學會。」

「而問問題跟引導確實是很棒的教練手法,好的引導,可以協助他人突破盲點,逐步往對的方向走,而錯誤的引導只會讓大家搞到一頭霧水,你熟悉引導的手法嗎?」

他:「嗯,我確實沒有受過專業的引導訓練。」

Gipi:「人總是如此,看了一些好東西,但只擷取你們想要的內容,而忽略前決條件或限制。就像給你一把關刀,但你忽略了他有82斤,而你自己的能力只能勉強舉起它,但無法舞動,你揮不動這把神兵,卻覺得這是刀的問題,而不去想想是否自己能力不足。」

「我給你的建議是,問問題跟引導、教練的能力要學習也要訓練,但在能力未成熟之前,請多琢磨自己的管理知識與技能,該有的流程、制度與表單不要遺漏,讓團隊先在對的基礎上往前走,在連你自己都沒搞懂的情形下卻硬要引導,只會讓彼此感到心累。」

關於訓練夥伴,我有沒有什麼方法,說真的,一直以來我自己都是無框做法,因為每個人的能力、個性、背景都不太一樣,而依事情的輕重緩急我也不見得每次對同一個人都用一樣的方法,你如果 by case 來問我,我可以很直接地告訴你做法,但如果要有個系統化的做法,或許可以參考一下我這張圖,或許能適用於 90% 左右的狀況。

1. 要求與期待

通常指的是對工作、對同仁的要求,而提出要求時,我的目的通常是識別能力到哪邊,然後根據能力來建立規則:如果一個人的連守時、主動回報等基礎概念都沒有,規則會訂的更嚴格些;但如果這個人基礎概念很好,也都能做到,那規則就會在工作的準時、品質、能力的提升等面向

接著是描述期待,這個期待通常是對工作成果以及個人表現的期待,包含準時完成專案,個人專案管理能力提升等。

這部分是針對一個人的基本工作素養的要求,但請記得一件事,許多人之所以不具備這些素養不是因為他天性如此,而是沒有其他人教過他。

分享一下我剛出社會時,學長是如何帶我的,而這些事,我本來也不覺得有多重要,可當學長告訴我原因,並身體力行這麼做之後,我覺得對我的幫助很大。

  • 會議要提早半小時到,把單槍跟其他軟硬體設施準備好。回過頭看看這些年來,光是在會議前等所有人事物ready,你浪費了多少時間,而準時的另一個好處是應得的消息你不會漏掉,提早到會議室這習慣,我維持到現在,公司的主管會議,除了負責招集的人外,通常我最早到。
  • 回應速度要快,不管做什麼崗位都一樣,別以為當研發工程師就不用學習服務,如果部門有活動或會議,我們往往也是扮演服務其他同仁的角色。
  • 第一個月訓練,第二個月開始訓練別人,對事情要很快上手,並能理解,為了要能教人,我們自己要先弄懂,問,是最快的,當時我們會把簡報一遍又一遍的講給他或同事聽,大家總會給很多的調整建議,有時覺得有需要這麼麻煩嗎?但後來開始帶人,才知道這是有意義的。
  • 著正式服裝,當其他 RD 們穿著輕鬆時,我們可是天天襯衫加西裝褲,有活動或課程時,還要打上領帶跟西裝外套。
  • 郵件發送的對象、格式、會議紀錄等,都有蠻多的要求,感覺像在商學院被指導如何在職場中求生存。
  • 早在10多年,我們的文件、培訓簡報、影片等早已是制式,按著 SOP 在執行。
把你的要求說清楚,不要讓大家猜,也不要期待大家一開始都能做到做好,你是 leader,這會是你的責任之一。

2. 經驗累積

接著進入實際工作階段,首先我會對我訓練的夥伴提問,提問的目的有很多,包含讓彼此了解現況,透過問答過程釐清問題與找出問題,而掌握問題後,根據不同的狀況會採取四種訓練方式。

指揮

這通常用在生手身上,他可能對現在做的事情完全陌生,但時間又有一定的緊迫性,我可能會直接告訴如何盡快搞定現在的問題,也就是我幫他做了決定,請他直接按著步驟做了,但通常當他完成後,我會再次進行指導或引導。

指導

這就是最常見的訓練過程,針對他不熟或不懂的點直接教,手把手帶著他走一輪,然後讓他自己去完成這項任務。

指正

這通常用在夥伴犯了相對嚴重的錯誤而不自知或者工作態度不當時,我會直接給予訓斥與指正,態度必須嚴厲,務必讓夥伴知道這是一件嚴重的事,不應再犯。

引導

這適用性很廣,只要錯誤的排除不急迫,我往往還是會用提問引導,例如:你覺得這錯誤發生的原因是什麼?如何避免?我們的制度、流程或人員那些地方應該補強才能避免這個問題?除了這個做法,沒有其他方案了嗎?

而透過指揮、指導、指正、引導的過程,我希望能達到明確的指正錯誤,引導反思與強化夥伴的自主學習能力。

在每次訓練結束後,會再次進入實作過程,並產出下一次的結果,並再次進入提問循環,一次又一次,直到工作順利結束為止,而這個提問循環的週期每次不一樣,對於比較重要的崗位,不容有失的專案,可能是一天一次或兩次;而針對比較寬鬆一些的工作,則可能是一週一次或兩週一次。


3. 能力

訓練的過程,不僅僅協助他完成他的工作,否則我只要透過指揮就可以了,但既然我們用了指導與引導,這代表我希望他能在訓練過程中把能力給培養起來,而知識內化、能力深植與誘發動機三個點,是我用來判斷這位夥伴是否掌握了該崗位或完成該工作的重要依據

怎麼判斷?只要他再次面對我各種刁鑽提問時,都能應對自如,我相信他就完全具備了所需能力。

好了,這是我嘗試把我平常用的方法以框架的方式來表達,但其實非常時刻非常手段,有 10% 左右的 cases,我會跳脫這些做法,可能更強勢,也可能更溫和,但這就視狀況來處理了。

而本篇提到的四種方法,大概可以解決絕大多數的狀況。

如果你覺得我內容寫得還不錯,歡迎訂閱我的電子報,我每雙週會發送一封電子報到你的信箱。訂閱連結在這,過往的電子報也在這:Gipi電子報

也鼓勵你可以將我的電子報分享給你認為有需要的朋友們,也許你的舉手之勞,將會改變另一個人的思維與習慣。

Read more

[徵才]方圓國際誠徵兩個新職務

[徵才]方圓國際誠徵兩個新職務

今年四月份,我加入了方圓國際擔任策略長,方圓是一家茶飲連鎖公司,旗下有兩個主要品牌「吃茶三千」與「喫茶小舖」。吃茶三千在海外 30 多的城市有約 130 家門市,喫茶小舖在台灣則約有 60 家門市。 我從去年底開始擔任方圓的顧問,主要協助梳理公司的管理制度、流程與阻礙成長的問題。四月份我轉任策略長,過去這一個多月,我除了 AI 的引入與建置外,我也花了大量的時間重新構思公司的整體策略。 我們進行了「未來十年不變的事」的策略探討,最終設定了十年戰略方向,三年目標,以及 2026 年的關鍵任務。 透過這樣深度的策略思考,我們也藉這個機會盤點了公司目前的人才缺口。 以下有兩個很關鍵的角色是我迫切在找尋的。如果你覺得自己或身邊的人很適合加入方圓,請自薦或推薦給我,謝謝。 歡迎將履歷投遞到:gipi@teashop168.com.tw 門市體驗經理(Store Experience Manager) 門市是接觸終端消費者的最後一哩路,也是品牌傳遞價值的關鍵接觸點。我們在全球因應不同的市場有不同的店型設計,

By gipi
克服 AI 焦慮的方法,唯有實作

克服 AI 焦慮的方法,唯有實作

2018-2019 年左右,線上學習在台灣整個大爆發,線上課程一大堆,每個禮拜都有很多線下學習活動。每天都可以看到大量的學習心得與活動心得,每個人講的內容都很有道理。全台灣好像瞬間變成一個知識島,所有人都學識淵博,而自己似乎懂得有點少。 知識焦慮年代 在那個時候,很多人染上了「知識焦慮」的病症。 害怕別人知道自己不知道的,擔心自己沒跟上世界的節拍,所以哪邊有新知往哪兒去,哪邊學習氛圍濃厚就往哪兒鑽。看起來是因為熱愛學習,但內心的煩惱其實是「害怕失去」。 害怕失去話語權,害怕失去社交談資,害怕失去機會,害怕失去競爭力,害怕自己不再是別人眼中領先的族群。 而克服焦慮最有效的方法,不是知道更多,而是實踐,從時間中獲得成果,獲得進步。 那些仍在學而沒有做的人,焦慮是無法停止的,因為他並沒有真的改變現況。 這也是當年為何我們想舉辦 case study、學習營、打卡、案例練習,並且鼓勵大家多多輸出的原因了。因為輸出,其實就是最輕量的實踐,而動手做,則是讓自己學有所用的基本配備。 在那個知識焦慮的年代裡,因為我本來就熱愛學習,也經常輸出,

By gipi
我如何與 AI 協作開發,我的開發步驟分享

我如何與 AI 協作開發,我的開發步驟分享

昨天到工程師場子分享,想說跟大家對照一下,現在是否多數人都跟我一樣,寫程式完全不手打任何一行 code,全部都是 AI 做的。 結果發現,現場只要有在用 AI 開發的人,多數時候真的都是讓 AI 來完成程式撰寫工作。 目前我的開發組合是 Claude Code / Claude Design / Fly.io / Github / Cloudflare,其他還有根據程式功能需要而使用的第三方元件。 做一個新系統的習慣是: 1. 跟 Claude 討論我想解決的問題,以及我的核心需求,中間我可能會用 Claude Cowork 做本地資料的分析,然後請他廣泛收集一下資訊,做幾輪 prototype 的模擬。確認方向是否是我所期待的。 2. 對完需求後,請他產出系統定位、限制、邊界與 PRD。 3. 把 PRD 跟幾個

By gipi
加快了速度,少了回饋

加快了速度,少了回饋

2022 年時我曾推出了一堂課《打造高效軟體開發團隊》。 在這堂課程中我繪製了一張軟體開發過程管理的架構,這張圖我從公司策略->產品策略->需求管理,一路到開發過程管理、交付、市場回饋,最後再回到產品需求管理。 當年我曾說過,軟體開發最重要的其實不是程式開發本身,而是 align 公司策略與產品策略,同時兼顧好短期需求,將需求管理做好。 但我們也可以看到產品需求管理是上述架構中最主要的節點,上承策略,下接短期需求,右邊則是成為所以開發計畫的起頭,同時還要承接來自市場回饋,並能持續優化管理過程與技術債務管理。 簡單的說,決定做什麼,決定了產品定位,決定先做什麼,則決定了策略重心。但要做出決定,除了對目標有清晰的認知外,更重要的是「回饋」。包含市場回饋、使用者回饋、利害關係人回饋(研發/行銷/客服...)。 這陣子透入 AI 開發後我對這張架構圖有一些新的想法: 首先,是生產力過剩。 因為 AI 不用休息,生產力幾乎沒上限,

By gipi