導讀：近期業界有大量有關什么是一個好的 CTO 的討論，本文是最近一周在美國碼農圈熱議的文章，高可用架構翻譯轉載如下。

[[174126]]

如果你還在整天寫文章辯論 PHP 是***的語言，那說明你還沒有成為一名真正的 CTO。

CTO 并不是團隊中最瘋狂的黑客，編寫代碼是 CTO 最不重要的工作。 在我看來， CTO 是一個能夠與其他技術人交流技術并引導他們更好的完成項目執行的人。 另一方面， CTO 是一個保護技術團隊免受外部干擾的人，并勇于在需要時承擔錯誤責任的人。

在很多缺乏技術人員的創業公司里，成為 CTO 并非難事。然而 CTO 在這樣的公司里，很大程度上只是這個公司嚴重過度疲勞的碼農。我主要想討論 CTO 這個位置需要什么樣的能力，并且如何養成這樣的能力。

我討厭技術部門只是實現了他人所設想的功能。 這樣技術部門與其說是公司的部門，不如說是一個技術外包團隊，因為它獨立于決策過程。 正如 Camille Fournier 在“ CTO 的作用”一文中所說，“ CTO 必須保護技術團隊不要成為一個不表達自己的需求和想法的純執行部門。

如果公司需要一個 CTO，那么這個人定義了對技術的長期影響的愿景。現在越來越多的企業不是使用技術，而是被技術定義。現代的一切都是建立在技術的基礎上，從零售電子商務到移動應用程序，當有人從內部推動技術發展的時候，公司就會因此獲益良多。 CTO 不能讓技術團隊僅僅成為實施者。

我曾經和不少 CTO 討論過關于如何讓公司的其他部門尊重技術開發的過程。例如，如何推廣單元測試。我會告訴他們：“這是我們要走的方向，這就是它將如何工作。”

總之，無論 CTO 說什么，就應該做成什么樣。如果 CTO 沒有這樣的技術決策權力，那他就不是 CTO，而是工程師小組長。

CTO 是一個業務戰略的工作，它定義了公司內部的技術方向。如果你討厭會議，討厭跟非技術人員交流，并認為所有經理都整天坐在一起，什么都不做，那 CTO 可能并不適合你。任何會議都是關于公司業務發展方向的討論，以及技術如何能夠幫助達到目標，或者有時技術如何為增長創造新的機會。

因此， CTO 必須了解企業和客戶的需求。從我的經驗來看，很多技術人員喜歡遠離“商業的東西”。然而，作為***技術官，這卻是***要事。技術決策不會在純粹的軟件或硬件問題中產生。大多數時間 CTO 應與產品經理同步，以保證產品戰略與開發進度一致。

最終， CTO 會創造一個允許團隊做牛逼事的環境。現在很大的問題是找不到足夠的工程師，每個公司都在尋找工程師，高質量工程師從來都很少，因此一個好的環境很重要。 CTO 應該知道如何構建好的環境，因為他們曾經是其中之一。如果團隊想要做 TDD，或配對編程或臨時服務器， CTO 都應該批準。由工程師來衡量這些變化帶來的影響。

思考技術研發的財務影響也很重要。一個創業公司可能允許自己使用***最酷炫的技術，而一個更大規模的公司則多半不會如此選擇。這一切都應該在投資回報的基礎上權衡，看看它給客戶帶來多少價值。因此，在大多數情況下，它是關于現有優勢和更新已有的基礎設施的平衡，而不是花費大量精力去做很難實現的工作。根據 80-20 規則，找到能通過 20% 的投入獲取 80% 的回報的那部分工作。

我曾經對未來的 CTO 候選人進行過訪談，他們會問：“為什么你堅持這個老版本，為什么你沒有用 React.js 重寫?”

對不起，我認為這不是一個好主意。有時候，老的遺留程序確實更難管理，但是重寫幾乎總是為客戶提供不了價值。

CTO 需要平衡團隊力量，好鋼用在刀刃上。建立一個只想要觸摸新技術的團隊是不可持續的。

構建一個階段來實現你最重要的事情。例如，我認為可靠性和安全性是任何軟件的兩個最重要的功能。因此，業務目標的任何變化都與之相稱。對于一個非技術人員來說，掌握安全相關的知識顯然是不可能的。然而這樣很可能會導致公司追求的目標會侵犯別人的隱私(安全性有問題)。 CTO 的工作的一部分是處理這個，并確保他們不會犯錯。

雖然我做的是技術，但是我認為技術應該是用戶不可見。 PHP 是否是***的語言，對于很多開發者是一個令人興奮的話題，但對于一個組織(公司)卻不是。我相信， 不關心這類事情是成為 CTO 的踏腳石——不過分關注技術細節，而是尋找團隊和其他一切。

成為 CTO 是關于實現更大技術影響的途徑，如何定義業務和如何幫助客戶。它有助于理解技術本身，但不僅如此。