醫療社群丁香園的 CTO 馮大輝離職了，炸出了科技產業裡的一個大問題：CTO到底應不應該寫程式？

具體來說，CTO在公司裡是幹嘛的？他／她到底寫不寫程式？該不該做程式審查（code review），親力親為給工程師做出榜樣？還是把握一下大方向、設計架構、管管工程師，提供一些培訓？抑或應該把行銷長以及「吐槽老東家」長的職位一併兼了？

在中國，大大小小的工程師們就這個問題已經吵成一團；那我們不妨去看看矽谷。帶著這些問題，我們問了一圈矽谷大小科技公司的 CTO、VP Engineering、技術合夥人，以及其他各種高階技術管理職稱上的朋友。

矽谷 CTO 寫不寫程式？

我們發現在矽谷，技術類公司比純網路產品公司多得多。大部分 CTO 不但會寫程式，程式也是他們日常最重要的工作內容。

Movidius 是一家研發低功耗視覺處理晶片的矽谷科技公司，現在已經擴張到了400多人的規模。 Movidius的 CTO David Moloney 在愛爾蘭都柏林工作，他負責管理一支超過 120 人的技術團隊，因此也設有一個「CTO 小組」，每天花 10-15 分鐘聽取小組成員的報告並作出指示。他常用的溝通工具是 Slack。

儘管如此，David 仍然很享受親力親為的工作風格，也是公司的技術迭代的主要功臣。他告訴我們，他的日常工作主要包括設計演算法、寫專利聲明以及幫助解決成員提出的技術問題。

我們按照專案和任務分成小組工作，我本人經常寫 Octave（Matlab）、C/C++ 來開發演算法，日常使用 GCC 和 Visual Studio（兩種編程工具）。我們使用 GitHub 來管理所有的程式。

除此之外，David 還會親自撰寫很多的專利聲明，而非將其交給下屬以及其他法律顧問。

David Meloney

其實不只David，採訪中我們發現，在矽谷，捲起袖子上陣寫程式對於 CTO／技術合夥人／高階技術管理人員來說簡直是家常便飯，幾乎不分公司技術團隊人數多寡。

一家由機器人 SLAM（定位、識別和行動技術）公司的共同創辦人匿名接受了採訪。他告訴我，因為是技術公司沒有設立 CTO 的職位，自己和另外一個創辦人每天大約有 8 個小時在寫程式，剩下 4 個小時做管理和溝通工作。

寫程式是每天工作主要部分，語言包括 Python、Java、C++、C 等。

這家公司的技術團隊目前有 8 個人，一半在開發演算法，另外一半做開放系統。

看完小公司，讓我們看看大公司是怎麼搞的。一位前微軟員工告訴我們，「印像很深的是在微軟，一個高階總監管理多於 300 個技術人員，還在堅持對核心部件進行 code review，時不時自己寫程式，程式質量還很不錯。」

微軟現在不設 CTO 職位，每個主要業務單獨設立部門，由資深的技術負責人擔任SVP——這些大多擁有十年以上的微軟工作經驗。

Oculus VR 是世界上最知名的VR 技術公司之一，在被Facebook 收購後成長迅速，員工總數從去年的數百人成長到今年的逾千人，其中技術人員比例很高，但該公司的大神級CTO John Carmack 仍是一副不寫程式不舒服的樣子。他討厭管理，由其討厭開會，曾經在 Twitter 上說：

沒有什麼比「取消：（某會議）」的郵件標題讓我笑得更開心了。

一位知情者告訴我，Carmack 超級不喜歡別人打擾他。他早年用過一些很奇怪的工具來提高自己的工作效率，比如工作的時候開始用CD 機放音樂，但凡有任何中斷（上廁所、收發郵件、被人闖進辦公室）就暫停，然後記錄一天下來暫停了多少次。著名遊戲開發者Richard Garriott曾這樣評價John Carmack在程式上的水平和造詣：

這個人啊，他的大腦分成兩個部分，一塊存儲Oculus的所有程式，另一塊存儲他創立的那個火箭公司的所有技術——而且跟內存一樣，他隨時能調取出任何一家公司、下屬專案裡面的任何一個程式細節。他真是讓我很沒自信……

John Carmack

矽谷 CTO 怎麼看待不寫程式這件事？

那家機器人技術公司的共同創辦人向我表示，如果技術人員不多，比方說10-50 名的話，CTO 不寫程式是一件挺不可思議的事，「與一般技術人員不同，他們只負責一小部分，我們需要了解系統的每一部分。」

但是在那些擁有50名以上技術人員的中型甚至大型公司裡，情況會根據公司而變化。

一個普遍的觀點是，CTO 應該根據公司需要轉變職能，甚至偶爾身兼多職。 Peloton Technology 的首席網路架構師Tony Li 認為，當公司需要擴張，那麼CTO得設計好系統架構；如果公司需要一個技術傳教者（比如在融資、招人或公關的時候），那麼CTO 也得是一個好的演講者……

當然，如果公司還是需要好工程師，那 CTO 照樣還得寫程式。總而言之，CTO 應該捲起袖子上陣的心態還是被大部分創立於21世紀的美國科技公司所接受。

Movidius 的 David Moloney 1985 年開始工作，曾在多家半導體業界知名公司擔任工程師、主任設計師、技術總監等職位。他認為CTO的確不用寫程式就可以管理，有什麼事情交給團隊成員也行——儘管他強調那不是他的風格。

如果我這樣做了，會感覺很不舒服。我認為作為CTO，首先應該是一個技術問題上的破冰者。

集客式行銷公司 HubSpot 總部位於馬薩諸塞州，已於早年上市，現在員工人數也超過了500人。其 CTO Dharmesh Shah 2014 年曾經回答過「CTO 應不應該寫程式」的問題。 他認為 CTO 應該寫程式，就像銷售 VP 得去銷售一樣。

Dharmesh Shah

除非那種已經很龐大的公司，在新創公司裡，每個人都要親力親為。我從來不相信純粹的管理職位。

不寫程式的 CTO 就失職了嗎？

或者：寫程式應該成為 CTO 的核心競爭力嗎？

這才是見仁見智的地方。大多數採訪對像都會告訴我，他們認為 CTO 不寫程式可以理解。比如有些經驗豐富，任職於大公司的 CTO，確實應該花更多精力把握大方向，設計架構、分配工作、優化整體性能、確保系統的穩定和安全。具體的執行和實現，由部屬來完成。

比如，有些大的公司不設 CTO 而是設工程副總裁 VP Engineering，但也能見到 VP Engineering 轉職 CTO（比如 Facebook），或者兩個職位共存的情況。曾在多家公司擔任 CTO 的 Vijay Venkatesh 認為，VP Engineering 更多負責現有產品，而 CTO 擔負的是設計未來專案，讓它與現有產品在技術上能夠更好融合的責任。

在這樣的公司裡，CTO 應該有著比普通工程師更全面的技能和更大局觀的視野。不可否認的是，CTO的程式能力越強大，越能跑好把公司規劃、業務需求透過技術落實的這個流程。程式能力是應該是讓CTO 龐大的技能樹更好地生根發芽的養分，而不是樹根本身。

CTO 應該會寫程式嗎？應該。寫程式是核心工作內容嗎？不應該是。用程式寫得好不好評價 CTO 合適嗎？不合適。

——這不是採訪對象們說的，是我總結的。

事實上，無論在矽谷還是中國，不少小型新創公司的早期技術員工都面臨這樣的狀況：行動端和web開發都得懂，平時還得維護自己的郵件／日曆系統，公司斷網了又要負責檢修和給營運商打電話，拉條電話線都得親自出馬。這哪裡是技術長，分明就是首席全棧苦力嘛。

而當公司發展起來之後，中美的情況卻發生了變化。

矽谷這些 CTO（除了 Carmack 大神），要不是一人扛起整個公司的技術運轉，就是在投入巨大精力親力親為。他們會這麼做的原因，也在最一開始提到過：技術對於這些公司的重要性，比技術對於中國大部分新創公司的重要性，都高得多；而CTO們需要考慮的技術之外的因素，也少得多。

而在中國，CTO 卻往往沒有辦法這麼去做了。中國科技圈太崇拜靠營運、靠打仗和修建城池獲得成功的神話。微信、淘寶、微博，哪一個不是這樣成功的呢？相比之前，技術的重要性太低，太不被外界重視。技術不會決定生死，產品做得差不多就行，靠推廣甚至靠搏眼球才能成功。這也是為什麼在矽谷，新創公司的CTO 們往往捲起袖子寫程式，而在中國這樣的環境裡，一名合格甚至優秀的新創公司CTO 卻得去考慮程式以外其他很多事，他們的價值，也就不能僅僅用程式來衡量。

所以，對於一個沒有技術缺陷、擅長營運、具備網紅人格，還為其帶來了巨大的影響力的 CTO，卻用單純用「寫不寫程式」來評價功過，並不太合適。特別是當我聽說，整件事情幕後真相的討論點已經從「匿名指責CTO不寫程式」過渡到「團隊拒不兌現 CTO 期權」的時候，我就更明白了：

指責CTO 不寫程式不過是一盆潑出去用來轉移視線的髒水，背後藏的，卻是希望藉著「程式之爭」來達到其否定CTO 價值、繼而撕毀契約目的的厚臉皮和小算盤。

本文授權轉載自：PingWest