我讀前員工論 Airbnb 三大失誤後的想法

月初時在 Facebook 上看到一位網友分享了 Airbnb 前員工談論前公司所犯的三大錯誤。

Airbnb’s Three Biggest Mistakes
This is the perspective of one lowly engineer who cared too much. For context, I spent 6 years at Airbnb from 2016 to 2022, first as a senior engineer, then an engineering manager and finally as a staff engineer.

他提到的三大錯誤分別是:

  • 擴張過程引入太多不合適的人,打壞了 Airbnb 的企業文化
  • 錯誤的技術選型,將技術大量遷移到微服務
  • 將客服部門外包,影響了客戶體驗

對於這三點,我的想法分別如下。


別搞砸了企業文化

我特別認同第一點,那就是擴張過程中,組織文化被擊碎了。

這一點我認為所有大型公司幾乎都有,組織文化這種東西,其實是一種環境塑造,你無法清楚說明白它到底是啥,但它就是存在於這個環境中,每個人的言行舉止都受它影響,而它的背後,其實是高階管理層的思維。

當高階管理層只有少數幾個人時,同步思維很容易,可一旦拿了投資人的錢,開始有擴張目標,此時團隊規模可能是以一倍、兩倍在成長,而且可能是連續兩三年都如此,這種過程就如文章所述,公司必然會引入更多來自大公司、有經驗的專業經理人與專家

如果本來公司的管理階層有 20 人,大家都是 Airbnb 原生文化掛的,他們很認同 Airbnb 的文化,但擴張過程的引入的管理階層是 20、50、100 個在成長,其中有部分人認同 Airbnb 文化,但也有很大一部分人適應得很辛苦,或者認為 Airbnb 的工作文化大有問題。這些人既然來到 Airbnb,他們肯定也想要帶來改變,因此,他們會提出他們的想法。

經營團隊為了達成成長目標,也為了借鑒好人才的好經驗,採納這些新主管們的建議,這完全合理。但要判斷這些決策是否吻合 Airbnb 文化卻是難上加難。畢竟很多問題,其實不在決策的那一刻,而在每個執行過程中,經營層看到了決策提案,但一般看不見執行過程

關於文化融入的問題,我們可以用以下概念解釋。

如果本來有 10 個人,這些人我們稱之為 Airbnb 原生種,他們的所有思維與行為都是符合 Airbnb 文化與價值觀。如果這時加入 1 個外來種,他進來後因為每天都跟這群原生種共事,即便他本來有些想法與原生種不同,一段時間後他也會被同化。因為這個地方就是這樣思考,這樣做事,你想好好做事就是融入這個環境。

10 對 1,有這樣的威力不奇怪。

但如果是 10 對 3,而且其中還有 1 位是屬於高階主管呢?難度就會高很多很多了,比例是個大問題,在幾公升的白色顏料中滴入一滴黑色顏料,你只要攪拌均勻就不容易發現,但如果滴了 10 cc,那狀況就不同了。

作者說規模擴張過快,一來是比例問題,二來是文化對齊(同化或融入)需要時間,但投資人不會給這樣的時間。

不過說真的,文化這種東西,在大公司的成長過程經常會經歷幾次重塑,有時是文化導致僵化,必須要調整,有時則是經營團隊的想法改變了,想要透過重塑文化來強調公司方向,有時則是經營團隊的組成改變,必須從初始團隊模式調整成傳業經理人團隊模式,這可能也會做出調整。

不是每個調整都有問題,但這種變化,對原生種們衝擊還是很大的,會覺得自己很喜歡的環境,竟然因為這些外來種而被改得亂七八糟。

但是否真的亂七八糟,還是原生種們沒有跟著公司成長呢?這沒人知道。

微服務 Microservice

第二點,資料有限,無法肯定,但或許也可以看看產品的長期方向,微服務的管理本來就沒想像的容易,但單體架構就很棒嗎?沒人能保證。

這種技術選型的問題往哪邊走絕對都有人支持,有人反對,但系統架構的有趣之處在於,它會跟組織架構有很大的關聯性

10 個人維護一個系統時,每個人都可以深入參與到這系統的方方面面,但隨著產品變複雜,一堆衍生模組跟服務持續開發,團隊人數也成長到 100 個人,此時你可能不得不做團隊分工,將模組、子系統、前後台的開發維護權限切給特定部門。如果團隊人數有 1,000 個人,很可能會再切一次。這種切分,很多時候是為了符合 R&R,也就是要讓權責清楚

你可能會說有問題時就一起扛就好啦,幹嘛分這麼清楚?

但這就是公司規模變大之後必然需要面對的問題,因為不是每個人都這麼想,而且也沒人能保證這麼想才是最好的,這種狀況下,組織架構就會大大影響系統架構。

團隊小的時候,所謂的好維護通常指的是純技術面,團隊長大後,所謂的好維護通常指我不用為了改一個東西要跟一堆人溝通,開一堆會議。我可以獨立作業,不需要經過其他人同意,這是我所謂的好維護。而為了做到後者的好維護,將架構拆乾淨,分工清楚,似乎是很重要的一件事。

不見得非得用微服務才能解決,但切分,從技術角度或管理角度,其實都是正常的一件事

外包客服

第三,客服團隊外包的議題,作者的立論主要著眼於客戶滿意度一來一回中間它認為影響是每年 10 億美元。我超級喜歡他將客戶滿意度提升 1% 能帶來 5,000 萬美元收益,正職客服可以帶來 10% 的改善,也就是 5 億美元收益這個概念。

因為我也是這種思維,從前客服被視為成本單位,但服務滿意度其實攸關續訂與推薦,我在《商業思維》這本書就有舉到一模一樣的例子,我認為客服是一個能創造長期收益的單位。

但我也能理解 Airbnb 會選擇將客服團隊外包這樣的決定,因為我也曾經歷過一樣的事。

一般會考慮外包客服,通常是因為在面臨跨國業務擴張時,客服團隊的建立與管理複雜度太高了。首先,如果你要在 30 個不同國家都有本地客服,他們說的語言不同,國家文化與民俗風情也都不同時,你的招募與管理都很難。其次,在快速擴張過程,你是要考慮自己慢慢建立,還是選擇將這項業務外包給專門做全球客服的 call center?

說真的,這又是一個選擇問題。

從年輕時候接收到的管理觀念裡,是不應該將核心能力外包出去,如果客服是 Airbnb 的命脈,那外包出去的品質將會直接影響公司存亡。而既然公司選擇將客服外包,那就意味著在經營層的想法中,客服並非核心。但就我印象所及,我記得 Airbnb 是早期談論 Customer Success 的公司之一,應該會很重視這塊才對。

不過這就是個商業決策,我們只能試圖解讀,但無法論斷對錯。

看這些案例其實非常有趣,但要直接評斷對或錯其實是非常困難的,因為我們都無法清楚的解讀當初做這些決策的真實原因。經營者經常得面對來自多方的壓力,而他必須在那樣的壓力下做出決策。

可又有誰能保證自己能想清楚,誰又能保證想清楚之後會不會犯錯呢?

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