神譯局是36氪旗下編譯團隊，關注科技、商業、職場、生活等領域，重點介紹國外的新技術、新觀點、新風向。

編者按：同樣一個人，到了類硅谷的科技公司之後爲什麼表現就跟着原先的傳統公司大相徑庭？傳統公司不同類型的公司在處理與工程師的關係方面的確存在很多方面的差異。不過，最大的是這個。“類硅谷公司”會把工程師看作是價值創造者，看作是創造性的問題解決者。而傳統公司只是把他們看作是工廠的工人。曾經在多家公司待過的Gergely Orosz總結了個人的感受。結合最近職場發生的一些熱點事件，看完本文之後，你也許也會有更深的感受。原文發表在pragmaticengineer上，標題是：What Silicon Valley "Gets" about Software Engineers that Traditional Companies Do Not。

劃重點：

類硅谷公司的軟件工程師有更高的自主權

是好奇的問題解決者，而非無意識的資源

他們擁有更加開放的環境，而不是被提防

他們受到鼓勵積極地跟其他業務部門互動

工程師跨部門直接溝通比逐級上報更高效

類硅谷公司會爲開發營造更加舒心的環境

更高的槓桿意味着更高的自主性以及薪酬

我曾有過之多家科技公司工作的經歷：從“傳統”商店和諮詢公司，到投資銀行，再到高成長的科技公司。我還曾經跟在初創公司、銀行、汽車公司、大型科技公司以及更“傳統”的公司工作過的軟件工程師交流過。豐富的經歷讓我對硅谷公司以及總部位於該地區以外的公司有了一份健康的樣本。

我已經注意到，有些傳統競爭對手（尤其是歐洲）總是無法理解或者在實踐中沒法實施的東西硅谷公司一直都很“懂”。這些做法對公司來說可以加快創新速度，對工程師來說可以加快個人成長，以及更好的“利用率”（這不知道是好還是壞）。反過來，硅谷的公司就可以支付更高的工資（的確如此），並且從同一個人身上獲得更多的價值。

在本文中，我會用“類似硅谷的公司”來指代能夠很好發揮軟件工程人員影響力的現代公司，而這些公司傳統上總部一般都在硅谷——雖然很多新公司不再如此。這是每一位工程師的工作產出可與Facebook或Google之類的公司相媲美的公司。他們也採用了類似的做法，往往可以吸引到其他“類硅谷”公司的人才。

這些公司比其他許多公司更“懂得”哪些事情呢？以下就是關鍵。

1.軟件工程師的自主權

在“傳統”公司，開發人員的工作事項一般是分配來的——一般是JIRA工單的形式。這些工單由產品（或項目）經理審覈，而且列出來要完成工作最關鍵的細節。對開發者的預期就是不多不少就做這些。整個過程沒有什麼可質疑的，除非要澄清工單的細節。

加盟“類硅谷公司”的話，這些幾乎看不到。是，他們也有項目，有項目經理和工程經理。但在大多數情況下，他們對工程師的預期（以及鼓勵）是弄清楚工作的“how”，包括做出更大的決定。在有的地方，每個項目都會由一名工程師領導，以便於的工作拆分。在其他地方，工程經理或高級工程師可以執行此項工作。不管最後是怎麼完成的，他們都會激勵所有工程師着眼全局，釋放自己，並解決他們看到的任何問題。

“類硅谷”公司讚美工程師的主動性。你往往會看到工程師對服務和功能提出建議，或者讓團隊騰出專門的時間來償還技術債務。對於經理來說，告訴工程師具體要幹什麼，把他們的工作分解成小塊，或者對其進行微管理是很罕見的。大家都是自我管理。

傳統公司對開發人員的期望是完成分配的工作。在類硅谷公司裏，對他們的預期是解決業務存在的問題。這是一個巨大的差異，會影響任何一位工程師的日常工作。

在傳統公司中，開發人員做要求去做的事情往往是自上而下層層傳達的。我曾經跟一個字銀行工作的人聊過。他們那裏的項目管理有6個層級。而開發人員排在最下面的兩級。決策只能從第三級開始進行。也就是說，從事這項工作的人基本都沒有發言權——這是設計使然。這家銀行一直努力解決軟件部門不奏效的問題，原因還需要我說嗎？

世界的等級視圖。一些傳統公司仍然是這種工作機制，最下層的開發者沒有決策權

跟那些公認的自己的工程師比其他任何人都能夠更好地在一線解決實際問題的地方相比一下。那裏的領導知道，把所有的相關業務背景分享出來，並賦予工程師執行的空間，這符合企業的最大利益。

傳達背景信息並給予自治權來進行決策是組織高效前進的動力。

2.好奇的問題解決者，而非無意識的資源

傳統公司往往把工程師看作是8小時的編碼機器。任何不在計算機前面敲編碼的時間往往會被看成是浪費。他們很高的代價來證明了這一點。我聽說有人是這麼推理的：

跟其他職能部門相比，軟件工程師的薪水更高。所以相應地我們得好好利用這幫人。我們不能讓他們閒着。

“類硅谷公司”會把軟件工程師視爲最適合解決組織所遇到的問題的人。他們僱的不僅是技術技能，還包括溝通和解決問題的能力。他們的想法有點像這樣：

軟件工程師是我們公司收入最高的人之一。這是因爲他們可以通過編碼和解決問題帶來最大的影響力。我們希望他們熟悉業務，這樣，當他們進行自己的“常規”工作時，還可以爲業務找到更有意義的機會。

在實踐中，有幹勁的工程師可以輕鬆地讓說什麼就做什麼的“工廠工人”的影響力倍增。在最壞的情況下，當工作規範清晰正確時，大家的輸出相同。但是，受到鼓勵去解決問題的工程師通常會停下來思考，然後再着手工作，一邊尋找機會去發揮更大的影響。在被問到是不是可以執行X之後，我在“類硅谷”公司看到工程師是這麼對話的：

“我做了一些調查，雖然我們是可以做X，但是如果可以縮小這項功能範圍而不會對業務產生影響的話，那我們就可以在不進行任何代碼變更的情況下發布這項功能，只需要改變一下配置文件就行了。”

“我擔心我們這個項目能不能交付，我覺得應該暫停這個項目。我看了一下競爭對手的工作，其中一個競爭對手已經推出了類似功能，但在監管機構對其進行調查之後又撤銷掉了。我們是不是已經跟法律團隊覈實過可以做？”

“我看了下我們積壓的項目，Y項目跟現在這個很相似。如果把X項目和Y項目結合在一起的話，我們可以用很少的開銷交付兩個東西。”

“我們要麼可以在舊的基礎設施上開發這個項目，但是之後就得遷移到一個月內建成的新的基礎設施上面；或者我們可以把項目推遲一個月，直到新的基礎設施準備就緒，以避免重複工作。如果沒有充分的商業理由必須在一個月內推出的話，我真心建議選擇後面這個方案。”

在鼓勵解決問題，注重結果而不是遵循指示的環境下，可以做出更好的決策。

3.內部數據，代碼以及文檔的透明度

硅谷公司的透明度很高。雖然也有例外——蘋果或Palantir可能會非常謹慎地向工程師提供儘可能少的信息——但我觀察到的大多數“類硅谷公司”都會盡可能地開放。他們會用符合GDPR、PII以及其他需遵循的監管要求的方式進行這種操作。

員工（不僅是工程師）經常可以訪問到實時的業務指標和數據源，從而可以自己寫查詢並創建自定義的報告。在Skyscanner這裏，我們每天都會收到有關當天收入明細的每日摘要電子郵件。在Uber，每週也都會發布一份有着類似指標的每週增長通訊郵件。

隨着公司的發展乃至於最後上市，這些信息就會合並起來。儘管如此，工程師仍然可以訪問自身組織的業務數據，從而幫助指導做出決定。

在傳統公司裏面，這些做法很多都是不存在的。工程師會拿到規範，更高級別的工程師會知道爲什麼要做出這樣的決定——至少他們的想法是這樣的。

4.接觸業務和業務指標

在硅谷公司，他們的預期是每一位團隊成員都瞭解自己的工作會對業務的哪一部分產生影響以及是如何影響的。團隊的目標很少只是發佈功能：通過發佈功能1來減少2％的客戶流失，或者通過發佈ProjectX來讓收入每年增加1000萬美元。

硅谷工程師會受到鼓勵，去跟企業的其他部門互動，去跟其他工程師以外的人建立關係。實際上，更多的高級工程師一般會這麼做：從跟產品經理進行1：1對話到參加客戶研究會議。但是我已經看到新入職的工程師直接就跟業務方面的利益相關者合作，而沒有任何人使眼色。

相比之下，傳統公司往往會讓開發人員沒有辦法跟其他的業務部門互動。但是他們不會明說。他們會說“我們要保護我們的工程師，避免他們被幹擾”。但是我曾聽說過有位工程經理想要邀請自己的團隊成員參加產品演示，而產品經理卻拒絕了這個想法的事情。“我們需要他們工作，他們分心的代價我們負擔不起。”是一個常見的藉口。

當傳統公司的工程師想着團隊之外建立關係時，他們經常會被講他們“精力不夠集中”，是“浪費時間”或者從事“與他們無關的事情”。這種“異常”活動往往會在績效評估的時候被打負分。

在我看來，公司給那些最好的問題解決者畫地爲牢，強迫他們“敲好你的代碼”就行的說法實在是太瘋狂了，但是這種情況正在發生。那些試圖用跟代碼行相關的指標來衡量工程效率的公司，就會懷疑自己的工程師爲什麼不以產品爲中心或者不具備產品意識。

5.工程師對工程師的溝通與逐級上報

如果你是一名工程師，並且對另一個團隊的工作方式有疑問時，你在傳統公司和在“類硅谷公司”的所採取的做法會有所不同。

傳統公司會鼓勵逐級上報，層層溝通。這既是爲了“屏蔽”工程師，又是因爲這些地方的經理更喜歡自己成爲信息中心，而不是放棄這部分的控制。對另一個團隊的疑問或者請求往往會是這樣的遭遇：

在“傳統”/等級組織裏面的溝通

“類硅谷公司”鼓勵工程師之間加強溝通，不要中間人。在所有情況下，這種溝通方式都要更快。而且在其他團隊的工程師無法提供幫助的情況下，這個過程還可以回退到那種經理的“傳統”模式，靠中間人來幫助促進討論：

溝通要有效得多

6.投資於一個不那麼令人沮喪的開發者體驗

2020年做開發可能會令人沮喪。但不是因爲寫代碼——寫代碼並不難！——麻煩的是周邊的東西。要設置好依賴。要部署到生產或測試環境。要做CI / CD（持續集成/交付）。要實現監視和警報。當你的團隊只有幾個人的時候，這些到不是什麼大問題。儘管如此，但問題仍會時不時地出現。

不過，隨着公司的發展，開發人員的體驗會變得越來越令人沮喪。這會從比較小的事情開始，比方說構建的時間變慢了，依賴項不斷增加了，或者需要進行跨服務的變更。然後還有哪支團隊負責哪項服務的問題，小小的遷移影響到了很多支團隊，乃至於最後要對整個工程重新定義架構。

框架和工具的變化很快，工具是很少能跟上的。關心工程師的公司會專注於解決問題，會迅速建立起各種基礎設施、平臺以及減少開發者體驗流失的SRE團隊。

僱用只專注於讓其他的軟件工程師能提高工作效率的軟件工程師？這聽起來似乎有違直覺，但對很多地方來說不是的。幫助這些公司更快地前進，並讓開發者情緒高漲，這可以收到豐厚回報。

7.更高的槓桿--&gt更高的{自主性，薪酬}

任何想要靠高新爭取到工程師的類硅谷的公司都需要創造出高槓杆，也就是這些工程師帶來的價值必須超過付給他們的薪水。這種槓桿作用既可以表現在規模上，也可以表現在企業的發展壯大上。減少把時間浪費在不必要的溝通等事情上，多利用工具，這些都可以增加這種槓桿作用。要賦予工程師足夠的自主權，讓他們爲企業做出貢獻，這就是你可以保持這種優勢的辦法。

如今，谷歌，Facebook等知名公司都在支付高薪，這屬於規模槓桿。這些公司的工程師往往會開發出數百萬客戶使用的功能。這種槓桿作用和增值本身就是回報。

更高的自主權--&gt更高的槓桿率--&gt創造出更高的價值--&gt更高的報酬（與此同時所有公司仍然能夠盈利）

類硅谷的創業公司所做的就是利用軟件工程師來發展業務。Fog Creek軟件公司的一位軟件工程師就爲ad classfields實現了一個一百萬美元的想法 。Facebook的工程師和設計師開發出了“點贊”，這個小小的按鈕影響到了數十億美元的生意：這讓Facebook可以發送（重新）定向廣告，並“跟蹤” Facebook網站之外的用戶。

如果上面提到的任何人是在“傳統”的環境下工作的話，他們的想法就會是：想想而已。“類硅谷”的創業公司會激勵工程師推進自己的業務點子，並實現出來，而他們會樂此不疲。對於有想法的人和企業本身來說，大家都過得更好了。

能夠讓工程師人盡其才的公司給他們支付接近或者高於市場最高價格的薪水會毫無問題。Basecamp就是能夠很好地利用工程師但不屬於“科技”大公司的很好例子。什麼意思？意思是說他們可以在全球範圍內給出跟舊金山市場一樣的基本工資，同時仍能保持盈利。

最大的總體差異在哪裏

不同類型的公司在處理與工程師的關係方面的確存在很多方面的差異。不過，最大的是這個。“類硅谷公司”會把工程師看作是價值創造者，看作是創造性的問題解決者。而傳統公司只是把他們看作是工廠的工人。

這種思想上的分歧使得有遠見的公司願意給工程師支付更高的薪水，並賦予他們更大的自主權。而作爲工廠的工人，其附加價值是非常明確的，是可以做規劃的。反過來，如果使用得當的話，一位富有創造力的問題解決者可以給企業帶來10倍的價值。給他們更高的報酬，給予他們更多的自由是行得通的，因爲只有這樣，你才能夠激勵他們爲企業創造出更高的價值。

一旦你在類硅谷的環境下工作過，就還很難再願意回到“傳統”的職場，在那裏，人人都扮演着明確的角色，而一旦你從那裏出走時，你就會眼前一亮。

作爲軟件工程師，在被看作解決問題者而不是工廠工人的地方工作才舒服。你現在是在哪裏工作呢？

譯者：boxi