聰明邀功,鞏固績效,讓自己被看見

聰明邀功,鞏固績效,讓自己被看見

還記得在 2008 年的時候,我在技術長的辦公室跟他報告一些專案的狀況,那時我還是一個小小的技術 leader,我如實的報告了目前專案的狀況,也匯報了一些現在專案的問題,並且針對這些問題做了蠻多的檢討。

我報告到一半時,技術長感嘆地說:「你們明明做得很不錯,結果從你口中講出來卻是滿滿的『檢討』。業務單位做 60 分可以講到 80 分,你們就算做了 90 分,說出來也只有 70 分。」

我一時沒理解他話中的意思,我回覆他:「我們確實沒有做得那麼好,還有很多需要改進之處。」

他說:「工作中所有的事情都有改善空間,但這並不意味著你們做得不好。你們搞技術的必須要學會 sales talk,要懂得銷售自己的價值,要懂得包裝,要學會邀功,否則你們是上不了戰場的,多數的功勞與機會都會被業務單位拿走,別人吃肉,你們只能喝湯。」

我問他:「那我要怎麼說才對?」

他告訴我:「做得好的地方要主動講,多說說好消息,不要總是等人問,因為多數人都是在出事時才會找你們,你們不主動講,大概只有研發的主管知道你們幹了什麼。要學習從商業價值的角度來陳述你們做出的貢獻,學習行銷自己,而不是只懂得用技術語言,那些別人聽不懂。」

在那次的對話中,帶給我很大的啟發。

學習邀功。對過去的我來說,邀功有點像在自誇,但技術長的想法讓我感到豁然開朗。他認為所謂的邀功,是將自己做得好的地方如實的傳達出來,這才能讓團隊享受到應得的榮耀。

試想,當你帶領著產品團隊,兢兢業業地交付了所有的專案,讓業務跟行銷團隊有可靠且穩定的產品可以推廣,也大幅改善了產品的品質,減少了 bug,提升了效能。但你沒說,因此所有人只會覺得最近都沒出事,很正常。

不過那陣子可能剛好發生了一次比較重大的事件,可能是產品出 bug 了,或者是專案延誤了,因此你被要求寫檢討報告,而且每週都要到管理會議上匯報最新的狀況。你跟團隊明明做出了很多的貢獻,但大家卻只記得你們最近出的大包

本來我就是默默做,幫很多部門搞定了很多問題,也花了比別人多一倍的時間投入在工作中,團隊也配合我這種刻苦耐勞的工作模式經常加班。但我們團隊獲得的機會卻沒有比其他人更多,我應該學習如何讓大家看見我們做的事,以及讓大家知道我們團隊的專業性跟能力。

在那之後的 10 多年,我一直朝著這個方向努力,讓團隊跟自己被看見,不過邀功也是有技巧的,要讓別人有感,否則就像自吹自擂,只會淪為別人笑柄。這個單元就來跟大家分享一下邀功的技巧吧。

有感的功勞

什麼樣的功勞才值得我們花心思邀功呢?日常的工作做好是必然的,可以拿來邀功嗎?出包後把問題解決,這能邀功嗎?協助其他部門把事情解決,這也只是跨部門合作的份內事情,拿來邀功適合嗎?

我的觀點是,只要一件事是讓人「有感的」,那就值得拿來邀功。所謂有感的,大多與老闆在意的事有關:

  • 對 KPI 有實質貢獻。你可能改善了某個工作流程,讓工作產出變穩定,或者服務品質變好了;也可能是提出了一個產品構想,讓業績成長更順利了;還可能是引入了一個新工具,讓團隊協作效率提升了。總之,你應該經常關注自己的工作到底幫哪些 KPI 起到正面的影響,即便那些 KPI 並不歸你都沒關係。你得讓大家知道,你對這個 KPI 的成長有具體貢獻。

舉個例子來說,客服案件數量可能不是我的 KPI,但因為我改善了產品的品質,我可以收集客服案件中與產品 bug 有關的數量及比例。然後比較前後期的數量跟比例變化。然後說我們每個月減少了多少件因產品問題的客服案件,也讓產品問題的案件比例減少了多少百分比。

  • 過去一直做不好,現在有所改善。例如果去產品品質不好,每個月都有 60 個 bugs,而最近三個月降到每個月 30 個,雖然還是很多,但算下來已經改善了一半。你不用誇大功勞,但可以給一張趨勢圖,然後說一下最近幾個月做了什麼,所以品質有明顯的改善。
  • 亂中有序,風險控制得宜。你可能接手了一個很有問題的案子,狀況可能很多,但案子基本還在可控範圍,只是經常得救火。在這樣的狀況下,多數人其實不敢開口邀功,畢竟事情還沒搞定。但其實你完全有本錢可以邀功,因為在你接手之前可能亂七八糟,但你接手後對狀況的掌握度很高,也掌握了可能的風險,並能提前處理。讓專案從兵荒馬亂到亂中有序,這其實也是一種可以邀功的地方。

除了上述三種狀況外,任何因為有你的介入,而變得比原先更好的事情,其實都可以拿來邀功。

邀功的場合

不過呢,雖然我們要學習邀功,但也不能不看場合,或者過於直白的做這件事。那到底什麼場合才是合適的邀功場合呢?我建議在以下幾種狀況下是最恰當的。

定期的會議上

第一個適合邀功的場合是在定期的會議上,這種會議的發生頻率蠻高的,或許每週會有一次,等於是你會有很多機會可以展現你的工作成績。但請務必記得,在定期會議上邀功,最適合的是在報告中凸顯你做了什麼,而不是口頭上直接提出跟報告無關的內容

你可以在報告中凸顯某個 KPI 的趨勢表現,讓老闆知道你最近三週成功找到與市場溝通的方法,將行銷轉換率從原先的 1% 穩定提升到 3% 以上。當你將這樣的數字攤出來,別人感覺不出來你在邀功,但你的老闆會知道你跟你的團隊做出了什麼貢獻

這就是一種聰明的邀功方式。

達成特定里程碑的進度匯報時

第二種場景,則是在達成特定成果時,自己主動匯報進度時提及。例如最近部門解決了產品一個兩年的老問題。你可以特別寫一郵件給主管報告這件事。因為主管不見得很清楚這個問題到底是什麼,所以你可以做一些前情提要,而提要的內容可以多放在效益的層面上描述。

例如過去造成多少財務損失,或者衍生多少成本,然後過去處理了多久始終無法根除。讓主管比較容易有個 before / after 的差異感。他心裡也會給你記上一個功勞。

特定里程碑也包含了各類型專案推進到一定狀態時,例如訂單簽下來,客戶同意結案,或者開發工作完成進入測試,這些時間點,都是你可以主動將成果同步給主管的時間。

一對一面談的時刻

跟主管一對一的場合很多,你可以是私下找他討論事情,也可能是定期的一對一,或者談績效時,這都是很合適的時機點。我會建議你善用每一次的一對一,不要什麼都沒準備就去,而是稍微整理一下近期工作中有哪些亮點,藉著一對一跟主管匯報,順便邀邀功。

邀功的時機點很多很多,只怕你不邀功,根本不用擔心找不到機會邀功啊。

邀功的禁忌

邀功很重要,但過往我也親眼看過幾次邀功翻車的案例,所以在這邊,我也要跟大家分享一些關於邀功的禁忌。

曾有一次,有個業務主管在公司的管理會議上直接說出「OOO 案子是在他團隊的努力跟折衝下順利拿下來的」。結果現場的產品主管心裡不舒服了,他直接回嗆說「如果不是你們一開始亂承諾客戶,會搞到最後一堆人要進去救火嗎?你怎麼好意思說是你們團隊努力才搞定的?」

這個業務主管不只沒有成功在老闆面前爭取到功勞,反而自己暴露了一個老闆本來不知道的問題,最後的結果是被老闆修理了一頓,而一開始搞砸的那個業務也被連帶處分了。

這個案例中,這位業務主管其實犯了一個很嚴重的禁忌。

禁忌一,不拿不屬於自己的功勞。

很多人以為所謂的邀功是搶功勞,這完全是個錯誤,你要拿到的是屬於自己的功勞,而不是把別人的功勞攬在自己身上。如果一件事是很多人一起搞定的,那你就不要說是你搞定的。你可以說你做了些什麼,但不要把所有功勞當成自己的。

這也是面試時很多人會犯的錯誤,明明自己是專案成員之一,卻要說自己「帶領團隊」成員完成任務。這種試圖搶別人功勞的做法,是職場的一大禁忌,因為這涉及誠信問題。

禁忌二,不要操弄資訊不對稱

在公司內,很多任務其實都是跨部門協作才能完成的,但總會有些人喜歡美化自己部門做的事,說其他部門配合度如何差,自己團隊的配合度又多高,承擔了很多非份內的工作之類的。而且這些話他從來不在其他人也在的場合說,永遠都是私下跟主管說。

這類人心裡打的如意算盤是,主管可能不會去求證這件事,當彼此的資訊不對稱時,他就能從中獲得好處。

這種人翻船的時刻會是何時呢?第一種狀況,主管是個會多聽聽其他人說法的人,第二種狀況,其他部門主管也不是省油的燈,你做的事他們也會做,主管兩相比對之下就知道誰在胡扯了。

操弄資訊不對稱不僅不會讓你獲得老闆賞識,反而很容易打壞主管對你的信任感。

禁忌三,不要誇大成果與過程

曾有個部門因為產品出了問題,花了兩個禮拜才把問題解決。在主管會議上該部門主管在報告時提到「我們團隊幾個人在公司待了三天沒回家,只為了把問題解決」。我當時想說真的辛苦了,但坐在我旁邊的同事悄悄跟我說:「別聽他胡扯了,他們就是昨天待比較晚一點,當我們部門沒加班看不見嗎?」

我那時心想:「何必呢?」

老闆當下還非常激賞,想要獎勵該部門幾位辛苦的工程師。

後來應該是有人看不下去,直接去跟老闆舉報,事後老闆不只沒有獎勵跟表揚,還冷凍那位主管好一陣子,而該部門的幾位工程師,也從本來的「勞苦功高」變成「對工作不上心」。因為老闆認為,如果他們早點用心處理,或許問題早一個禮拜就解決了。

功勞本來就有小有大,沒必要老是用誇大的形式來獲取超出自身貢獻的功勞。這是一種欺騙,是一種職業操守的問題。

如果你是一個有職業操守的人,你通常不會踩到上述幾個禁忌,我相信大家都是聰明人,懂得拿捏這個份際。

結語

邀功也好,討拍也罷,我們的目的只是讓另一個人知道我們到底做了哪些事,對公司、對部門帶來哪些效益,讓自己的貢獻被看見。學習邀功,你的成果才不會被埋沒,尤其是後勤部門與幕僚部門更是如此。

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

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

Read more

普通人悖論

普通人悖論

今天跑步時聽了一本書,書中提到一個「普通人悖論」。聽著有趣,因為似乎解答了我這幾年的一些自我認知的疑問。 「我們一般人....」 「對普通家庭來說....」 我們總看著成功人士的故事,閱讀那些不平凡的案例,可到最後,我們還是會回過頭來告訴自己「我們就是個普通人」。 我們渴望不凡,渴望能活出屬於自我的人生,但我們卻又認為自己無法脫離普通人的路徑。20 多歲出社會,謀得一份工作,接著兢兢業業數十年,從基層爬到高層,一輩子在職場上與人競爭。當我們看到那些跳脫這種路徑的人時,我們又說服自己「那是別人」、「那是獨特個案」。 我們心理渴望自己也能是獨特個案,但又不斷說服自己「我只是個普通人」。 這種心境,讓我們沒有勇氣去追求屬於自己的人生。 在聆聽這段時,為什麼我會特別有感觸呢? 在我今年撰寫的新書《用商業思維優化你的人生選擇》中我提到,每個人的人生都是獨一無二的。你不見得要像他人一樣功成名就才算非凡,你能做自己喜歡的是,成為自己想要成為的樣子,活出自己的人生,那你就是個非凡的人。 因為其他人很難活得像你這樣。 我內心是堅定相信這件事的。但我卻又經常在一些時刻,會將「我們一般人」

By gipi
如何快速熟悉一個產業?

如何快速熟悉一個產業?

什麼是產業,什麼又是行業? 有人會說電子業、食品業,也有人會說製造業、零售業、服務業,這兩者指的是相同的概念嗎?其實這邊隱含了兩個概念,也就是業種跟業態。 業種,是行業種類,以販售的「商品種類」區分所屬行業。例如賣建材的建材行、賣文具的文具店、賣水果的水果店或賣米的米店等。這些業種店看招牌名稱就可得知該商店販賣哪種商品。 業態,是行業型態,則是以該店家的「經營型態」區分所屬行業。例如提供即時、方便服務的便利商店;提供專櫃及流行品的百貨公司;提供量大、低價的開架式民生消費品的量販店等。這類商店,無法從其名稱辨別產品。通常是提供「一站式購買服務」為訴求,並提供其他相關的附加服務。 典型的業態,其實分兩大類,製造與流通。製造商負責製造產品,流通商負責將貨物流通到消費者手上,並因應消費者的需求,擴大產品品項,增加服務,而大家常講的零售與批發,其實也歸屬於流通範疇中。 舉例來說,生鮮食品經生鮮處理中心,將生鮮品分類分裝,這是製造的範疇,大盤商集中所有產品,

By gipi
當 vibe coding 已成必然,軟體開發會有什麼變化?

當 vibe coding 已成必然,軟體開發會有什麼變化?

當 Vibe coding 興起後,有愈來愈多的資深工程師的工作重點轉換到修復 AI 寫出的各種 bug。因這個現象,有些資深工程師們打趣地說,他們現在的任務像是專門處理這些 vibe coder 寫出來的爛 code。而這個職務稱為 Vibe Coding Cleanup Specialist。 我個人絕對支持 vibe coding,因為這是軟體開發的典範轉移,用得好的話可以大幅提升生產力,加上 AI 顛覆職場的趨勢幾乎不可逆。擁抱變化會比抗拒變化更明智。 這讓我回想起 2005 年剛出社會時,因為我起步的程式領域是 C#.net,使用的開發工具是 Visual Studio。C# 的好與壞我就不提了,但在當年,Visual Studio 這工具被稱為地表最強 IDE 應該是沒問題的。 它有多方便呢?所見即所得,元件直接拉到畫面上,出來的畫面就長那樣,

By gipi
主動改變或被動被改變

主動改變或被動被改變

「像恆溫器(thermostat)一樣改變環境,而不是像溫度計(thermometer)一樣被動測量環境」 如果環境不好,但你又想繼續待在這個環境,那你能做些什麼? 分享兩個以前團隊中年輕夥伴的故事,一個剛畢業,另一個則只有兩年工作經驗。 第一位是當時公司招募的儲備幹部,剛進公司月薪就有兩萬人民幣,這薪資高過公司內最少 80% 以上的員工。公司對這些人有著高期待,也為他們安排了一系列入職培訓,希望將他們培養成公司未來的骨幹。 而在計畫開始時我也擔任了面試官的角色,在面試過程我聊到一位很適合做產品的年輕夥伴,他在幾家網路公司都有實習經驗,而且能清楚的說明他負責的工作項目,針對我的提問「如何優化數字」、「如何做計畫」、「如何修正錯誤」等問題都能回答得很好。 面試後我跟 HR 說,我想跟這位談談能否放棄儲備幹部計畫直接到我們部門任職。HR 說只要對方同意就沒問題。 我找這位年輕夥伴聊,清楚地跟他說我為什麼希望他能加入我們團隊,可同時也跟他說我們給的薪資肯定不如儲備幹部,而少了這個光環,他要被看見就得靠自己的表現了。但我能跟他保證的是我們部門這個職務能讓他成長得更快。 他跟我說:「

By gipi