本篇文章原本在 2014 發表於 Airbnb blog ，經作者 Mike Curtis (時任 Airbnb VP of Engineering) 同意後翻譯於此。
譯註：此文寫於 2014，故與現在 Airbnb 部份制度已有不同，但仍值得參考。
如果你剛去過 Airbnb 的辦公室，你可能會注意到一些事情：鼓掌。我不確定為什麼，但有時一個團隊會為一個小小的勝利鼓掌，然後更多的人會開始鼓掌，然後突然間整個產品和工程區域都充滿了掌聲和歡呼聲。大多數人不知道他們為什麼要鼓掌，他們只是想表示支持和玩得開心。
也許這就是好的文化的一個表現：預設支持的態度和慶祝他人的成功。每個公司都有某種文化。有些公司一絲不苟地維護它，有些公司只是讓它隨意發展並祈禱它不會長歪。無論用哪種方式都避免不了一個現實：好的文化創造了一個人們可以盡最大努力工作的環境，壞的文化則令人覺得身心俱疲。
我在 Airbnb 已經一年多了。之前我曾在包括 Facebook 和雅虎在內的許多公司擔任工程師和經理。我想分享我們為使我們的工程文化變得很棒而所做的一些事情。
工程師對自己的貢獻負責
我們的核心理念是：工程師對自己的貢獻負責 (engineers own their own impact)。每個工程師都有責任為我們的用戶和公司創造儘可能多的價值。
我們招聘時看重解決問題的能力。當你擁有一支強大的問題解決者團隊時，推動公司向前發展的最有效方法是將決策權交給個別工程師。我們的文化、工具和流程都圍繞著為個人貢獻者提供準確和及時的訊息，他們可以使用這些信息做出重大決策。這有助於我們更快地疊代、試驗和學習。
要創造這種環境需要幾個條件：工程師參與所有專案的目標設定、規劃和集思廣益，他們可以自由選擇自己從事的項目。他們還可以靈活地平衡長期和短期工作，在管理技術債務的同時對業務有貢獻。這是否意味著工程師可以為所欲為？不。他們與團隊其他成員（包括產品經理、設計師、數據科學家和其他人）一起定義和優先考慮有影響力的工作。
同樣重要的是，工程師可以直接查詢內部資料，我們預設資訊共享。工程師擁有的資訊越多，他們工作的自主性就越大。一切都是對內部公開的，除非有明確的理由不這樣做（這種情況很少見）。這包括查看分析數據倉儲、每週專案進度更新、CEO 員工會議記錄等等。
這種環境可能很可怕，尤其是對於新工程師而言。沒有人會確切地告訴您如何產生貢獻。這就是為什麼我們四個價值觀之一是優先幫助他人 (helping others takes priority)。在我們的團隊中，沒有人會因為太忙而無暇提供幫助。例如，在這裡，剛從學校畢業的員工會與一個能幫助他們的團隊配對，以找到得以發揮長才的挑戰。無論是技術問題還是戰略問題，工程師總是將互相幫助放在首位。
結構化的團隊，流動的職責
每個人之所以能夠決定什麼是有貢獻的，是因為有明確的公司戰略來引導決策過程。這就是為什麼我們設計公司策略時，要簡明且可量化。它要簡單到可以寫在一張白紙上，而且 Airbnb 的每個員工都知道他們的職能與大局有何關係。了解你的團隊的目標是什麼可以幫助你決定如何使用你的時間，從而最大限度地減少浪費時間辯論存在主義的問題。而且因為我們的每個主要目標都有一個數字目標，我們可以衡量各種專案的有效性，從我們的成功和失敗中快速學習。
我們的團隊結構也對應到我們的公司戰略：我們會組成關係緊密的工作小組，一般只有 10 人或更少，以求高效率的溝通管道。團隊主要由工程師、產品經理、設計師和資料科學家組成，一些團隊則與公司內的其他部門合作。職能之間有很強的協作：付款團隊包括財務人員，開發內部工具的團隊包括客戶體驗專員。工程師和設計師一同搭檔並即時的弄清楚如何完成某些東西是很常見的，最好的想法往往來自密切合作。
今年，我們有十個團隊專注於產品開發，四個團隊專注於技術基礎建設。每個團隊都關心 Airbnb 業務上的一個特定面向，並以公司整體戰略為指南，每季度定義自己的子目標和專案。
儘管每個團隊都擁有不重疊的負責業務，但跨團隊協作是常見且被鼓勵的。例如，我們有獨立的房東和房客團隊，因為我們傾向於將房東和房客視為獨立的用戶指標，各自都有自己的一套需求。但由於房東和房客之間的互動是讓 Airbnb 與眾不同的地方，因此這些團隊為對方的產品路線圖提出建議、分享目標並在專案上合作，同時保持足夠的獨立性以建立關於其用戶的使用情境和需求的特定專業知識。促進團隊間的協作有助於我們填補不足之處。
工程師更換團隊或為超出其直屬團隊範圍的領域做出貢獻是很常見的。例如，以產品為重心的團隊在其專案工作流程中為改進我們的基礎設施做出貢獻是很常見的。工程師可以自由更換團隊當另一個小組的工作更符合他們的興趣和推動影響的能力時。事實上，這是被鼓勵的。管理者可以促進這一過程，但個人需要找到他或她可以產生最大影響的團隊並採取行動。
產品開發過程中的文化標準
Airbnb 的開發流程特意設計成很靈活。我們不希望用各自不同的方式開發，但我們也不希望過於標準化，以至於錯過新出現的更好的工具和方法。我們相信培養個人良好的判斷力，而不是在整個團隊中強加規則。
當我們的流程發生變化時，它會從團隊內部有機地發生。程式碼審查 (code review) 是一個古老但很好的例子。多年來，我們一直能用 pull request，但我們從未強制要求使用它們，而且從以前就有許多工程師並沒有將它們作為工作流程的一部分。事實上，在早期，直接 merge 自己的 change 到主 branch 並佈署到網站是很常見的做法。這有點像蒙著眼睛玩雜耍電鋸——當你佼倖成功時看起來很酷，但最終你會失去一根手指。
在某個時候，一些熱心的工程師開始在我們每週的工程全體會議上高調分享出色的程式碼審查。他們會高調分享他們在一周內看到的一些最有幫助或最周到的程式碼審查。很快的，更多的工程師開始採用 pull request，並且達到了一個臨界點，如果您不要求進行程式碼審查，這會變得很奇怪。直到現在，這就是我們開發時的標準作法。
與此同時，我們工具的進步反映了這種文化轉變。一小組工程師自行構建了我們的持續性整合 (continuous integration) 基礎設施，使工程團隊能夠在每個人合併程式碼分支後的幾分鐘內運行整個測試套件。使用工具降低了遵守良好行為的障礙，也促進了團隊的文化變革。
這是一個例子，但還有無數其他例子，包括我們如何採用我們的專案管理工具和問題追蹤系統 (bug tracker)。當我們發現一種更好的做事方式時，我們會讓大家對這個想法有更深的認識，然後讓它依靠自己的優點逐漸流行起來（或沒有流行起來）。通過這種方式，團隊在完成工作的方式上有很大的靈活性，我們也為新的好想法的出現創造了機會。
任何工程師都可以為程式碼庫的任何部分做出貢獻。所有程式碼倉儲 (repositories) 都對所有工程師開放。這是可能的，因為我們的自動化測試文化、我們的程式碼審查以及我們監控檢測線上 (production) 異常的能力。這裡的標準禮儀是從開源世界借來的：維護你正在更動的程式碼倉儲的團隊中的某個人，應該在你把程式碼合併之前檢查你所作的更動。
這種模式讓工程師更容易自己除去障礙 (unblock)。與其期待另一個團隊把你想要改的功能加到他們優先列表，並等待他們有時間完成它，不如自己動手並讓他們審查。程式碼審查會很快進行，因為，優先幫助他人是我們的文化。
一旦程式碼被合併，工程師部署自己更改後的程式。在一天之中，我們通常部署網站 10 次或更多次。我們的構建和測試過程運行時間不到 10 分鐘，我們可以在大約 8 分鐘內完成完整的線上 (production) 部署。因為它是如此之快，我們要求工程師在合併後立即部署他們的更改程式碼。對於對線上系統做一些頻繁但微幅的變更，代表著程式碼衝突的可能性較小，並且在出現問題時更容易調試。在您部署變更程式碼時，在我們的工程聊天室中待命是平常的禮節。我們的機器人宣布部署開始和完成的時間，工程師宣布他們已經驗證了他們在線上系統中的改動。在此期間，工程師還負責觀察指標以確保不會發生任何不良情況。
當然，有時也會有不好的事情發生。在這些情況下，我們可能會回復網站到前一個版本，或修復並佈署修復的新版。解決問題後，工程師會與網站可靠性團隊合作編寫一份不究責 (blameless) 的事後檢討報告。我們將所有事後檢討報告保存在我們內部開發的事件報告工具中。事後檢討報告提供了重要資訊，作為我們改進基礎設施可靠度時的方向。
職涯發展、專業跑道和影響力
我們的另一個信念是工程師即使擔任個人貢獻者 (individual contributor) 也能在職涯上像他們擔任管理職走得一樣遠。工程師可以通過兩條途徑發展他們的職業生涯：管理職或個人貢獻者。薪酬等級是平行的，所以擔任 Airbnb 的工程管理職不會賺比較多錢。
事實上，轉職為一名技術主管並不是升職；而是改變你的工作重點。主管是促進者 (facilitators)。他們的存在是為了為工程師掃清障礙。這可能是職涯的障礙、擬定優先順序或技術上的協助，幾乎任何可能成為障礙的事都是他們該幫的。他們的主要責任是支持周圍的人。
我們也看重我們技術主管們的技術實力。每個主管每週都要參與幾十個技術決策。如果沒有強大的技術背景，他們在該過程中的影響可能會導致糟糕的結果。出於這個原因，所有技術主管都從個人貢獻者開始。當他們熟悉程式碼和開發實務時，且，更重要的是，當他們覺得這是一個自然的轉變時，他們就可以過渡到管理層。我們不空投技術主管。
個人貢獻者的主要職責是技術執行，以對業務產生影響力 (impacts)。他們負責尋找和執行高影響力的工作。在那個過程中，另一個價值是讓每件你碰過的事物都往更好的方向改變 (leave it better than you found it)。每個專案都應該提高我們的技術基礎。這一責任落在了個人貢獻者身上，這意味著工程師正在推動技術決策，並讓彼此遵循技術工作的高標準。這也意味著工程師會協商功能權衡和截止日期，以確保有足夠的時間維持工程品質。
我們幫助工程師進步的另一種方式是幫助他們在公司外部建立個人形象。我們通過 nerds blog (註譯: Airbnb eng blog) 上的博文和開源來做到這一點。我們相信，任何不是我們獨特業務核心的東西都可以推動成為開源軟體。我們一直希望將有用的技術回饋社區。我們鼓勵這樣做，以幫助提高人們對我們正在進行的工程工作的認識，並展示我們工程師的一些最佳作品。
結語
目前，我們仍在建立基礎和實行方法，以因應我們在未來幾年內所需。當我們成為一個更大的團隊時，今天看起來微不足道的事情將被放大 10 倍。這是一個很大的壓力，但看到成功的實驗並成為文化的一部分，或者看到某些事情失敗並被揚棄也很有趣。
不把文化搞砸 是最重要的。當您快速成長時，保持創意和有趣的環境很重要。我們的工程團隊每週五有一個小時的會議，用來作技術演示、動畫 GIF、掌聲、讚賞和歡呼。我們每年舉辦兩次為期多天的黑客松，過去每個黑客松都值得大書特書。我每週都會與一小群工程師會面，只是為了提出問題並聽取有關我們如何改進的想法。我們有一個書呆子洞穴 (nerd cave)，工程師們可以在那裡閒晃，一邊工作一邊聽唱片。我們大概可以另寫一整篇關於我們如何保持關係並享受團隊樂趣的完整帖子，但我會把它留到另一天。
Airbnb 的特別之處在於，我們的文化將工程師與公司使命以及彼此之間的聯結比我見過的任何其他地方都更加緊密。工程師在這裡擁有自己的影響力，優先幫助他人，預設共享資訊，並不斷使程式碼比他們原本的更好。我們的文化使工程師能夠做到最好，並幫助他們每天都興奮地上班。
譯註：Airbnb 工程師自稱是 nerds 和 nerdettes
Pesty's Articles 