企業成長,人人有責

企業成長,人人有責

大家好,我是 Gipi,上一篇我們跟大家聊到指數型成長的概念,本篇我想進一步聊聊高成長型組織的管理邏輯。

Apple 的「不同凡想」(Think Different),Amazon 的「永遠抱持 Day 1 心態」,Facebook 的「破除陳規」,這其實都在宣示著持續進化、改變、不要讓自己陷入僵化的態度。

接著將這樣的價值觀貫串在整間公司,並讓這件事在所有員工的日常工作中持續發生,直到成為公司的文化與基因。

當所有人就會認為公司的成長,自己是有一份責任在的,那便會自動自發的思考自己所做的每件事,如何對公司的成長做出貢獻。

企業成長,真的人人有責嗎?

還記得在 5.6 年前,我曾在一些文章跟公開的演講中提到「公司的沉淪,你我都推了一把」。

我當時舉的例子是,很多人總會隨口說「這是老闆該煩惱的問題」、「這種事提了也沒用」、「我們做好自己手邊的事就好」,這樣的行為不只影響到自己,更影響到其他同事,當所有人腦袋裡都是這麼想,也都是這麼做的時候,企業文化就會愈來愈往壞的方向去了。

當時我說:「如果我們換個方式呢?如果老闆的煩惱我們也能幫上忙,如果換個方式提案可能會通過,如果幫助其他同事做好他的事,我們做起事來也會更順暢,那我們是不是應該去試試看呢?」

過去我在企業內推動商業思維,我告訴 PM:「你應該去釐清這個案子的目的跟背後要解決的問題,以及解決之後可以帶來的具體效益。」

PM 跟我說:「但老闆不會想解釋這些,我們不是就把他交代的事情做好就好了嗎?」

我說:「你愈是不問,愈是容易做錯,老闆不會重用你,自然就不想跟你說,因為你並不重視他的需求。」

我跟 RD 說:「我們需要掌握每個需求背後發生的脈絡,才能對症下藥去處理,並在處理好之後去觀察問題是否被解決,如果不這麼做,你們根本不知道辛苦加班做出來的東西到底有沒有創造價值。」

RD 說:「這應該是 PM 要搞定的吧?」

我說:「如果 PM 沒法做好呢?他可能有疏忽的地方,或者有些地方沒你們這麼懂,但我們卻將自己工作的價值全部寄託在他身上,風險會不會太大了些?」

我跟 HR 說:「HR 招了很多人進來,但這些人是否適任,是否解決了當初招募這個崗位所要解決的問題,這些如果沒有做後續跟進,那 HR 要如何去判斷我們的招募做得好還不好呢?」

HR 說:「是否適任這件事由用人主管決定,HR 沒法干涉。」

我說:「如果全部交由用人主管決定,但這些主管並非人力資源專業,他們不熟悉選用育留的各種訣竅,我們卻全部交由他們來決定,那 HR 要如何幫公司建立起扎實的人才資本呢?」

老闆決定的事,他對自己的決策負責,我照做就是了,

需求來就做,做對或做錯這就聽 PM 的,反正他要負責,我照做就是了,

用人單位要什麼人我就給什麼人,反正錄取了代表用人單位自己同意了,這人是好是壞他們自己承擔,我的責任只到這個人進來為止。

這樣子的對話,每當我到一家新公司時,我總會聽到無數次。

其實,多數企業的員工並不認為公司最終的成果跟自己有什麼關係,因為從小到大的教育都叫我們認真做好自己手邊的事,然後跟其他人分工,各自把各自的事情做好就好。我們每個人都負擔有限的責任,關注的點在於我是否完成了任務,而不在我是否創造了價值

但這樣的心態,對企業或者對個人來說都是一種傷害。

對企業的傷害是,當所有人都只顧著做好手邊的事,只要溝通環節中有任何一個節點有落差,最後的結果就不會是好的,而所有人投入的努力很可能都白費了,這等同於這段時間的人力與資金全都浪費了。

對個人的傷害是,你永遠不知道自己認真投入時間、精力所做出來的東西是否有價值,你不會獲得成果,也不會有代表做,更無法獲得對成長有幫助的回饋。

但是,員工要怎麼對成長負責呢?

「我只是一個工程師,又不負責業績,怎麼對成長負責?」
「我就是個 HR,成長這件事離我太遙遠了吧。」

對於成長,多數人想像的就是業績,但其實推動企業成長的要素並不只有業績,這個觀念我們在企業經營的本質中有提到,企業必須要有足夠的利潤以創造自由現金流,並進一步投入在市場擴張與持續研發的工作上。所以在營收之上,還有利潤、自由現金流、市場擴張、研發、使命跟願景等要素在。

除此之外,我們也談論過很多次關於數據脈絡的概念,藉由數據脈絡,我們可以很清楚的解構我們手邊的工作跟公司想追求的價值之間有什麼樣的關聯性。

然後在績效指標管理的核心觀念中我舉了電話客服的工作跟營收成長間的關聯性怎麼看,以及怎麼算,讓每個人都有機會對應到自己的工作對公司營收成長的貢獻,而當每個人在日常工作中,都可以仔細思考自身對公司的價值,那公司就可能在方方面面上進步。

客服部門做好每次的服務,服務滿意度提高,客戶回購率上升,公司業績會提升;

產品部門把產品做好,客戶對產品的評價提高,更願意做出推薦,公司業績提升;

研發部門把運用更好的技術,並遵循開發流程,減少錯誤,產品品質提升,退貨率降低,客訴減少,滿意度提高,回購率跟業績都跟著提高;

業務助理將潛客名單整理好,幫業務做好預先的電話開發,在業務拜訪前先做好資料準備,提高了業務開發的成交率,公司業績也會提升...

當我們順著數據脈絡,所有人都朝著公司當下最重視的指標而努力,這家公司就會進入指數成長狀態。

單一部門的改善影響很有限,但是當多個部門一起改善 10%,就會出現 110% x 110% x 110% x ... 的指數型效應,這也是最扎實的指數成長方式。不要期待單點式的爆發成長,那運氣成份太重,也會導致不確定性及風險提高,企業經營必須要如這篇文章所提到的一樣,將資源做有效配置,才能兼顧效益與風險。

結語

企業必須在內部建立起成長人人有責的文化,並運用商業思維讓所有人對齊方向與目標,找出每個人工作價值,並在公司經營的方方面面作出改善,企業才能達成有機且指數級的成長。

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