CTO到底該不該寫程式?
CTO到底該不該寫程式?

醫療社群丁香園的 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 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 上說:

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

j-carmack-twitter

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

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

John Carmack

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

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

往下滑看下一篇文章
從切菜到乾燥加工!宜展如何結合桃園市政府創業資源,以AI開拓農產加工第二成長曲線?
從切菜到乾燥加工!宜展如何結合桃園市政府創業資源,以AI開拓農產加工第二成長曲線?

走進蔬果加工廠,同樣是100公斤高麗菜,最後能做出多少成品?答案不見得相同。氣候、產地與品質影響原料條件,客戶要求的切法、重量與交期也各不相同。對曾任科技業研發主管十多年的宜展科技農業執行長林佑澤而言,這是與科技製造截然不同的世界。

「農業部分全部都不一致。」林佑澤以青江菜為例,即使機械手臂已經訓練好辨識特徵,面對形狀各異的蔬菜,仍難以判斷該從哪裡抓取。農產品的天然變數,卻得面對學校團膳、連鎖餐飲、航空空廚等企業客戶對品質與交期的要求。如何讓加工流程穩定運作,成為宜展投入數位轉型的起點。

從紙本、LINE到數據,先把現場經驗留下來

目前宜展一年處理數千噸蔬果、服務超過120家企業客戶,業務涵蓋採購、截切、清洗、包裝與配送。林佑澤觀察,農產加工的關鍵經驗往往掌握在資深員工手中:該買多少菜、原料損耗多少、訂單增加又該安排多少人力,都仰賴現場判斷。

「主要就是把人的經驗變成數據。」林佑澤說。過去客戶透過LINE或紙本下單,現場靠人工整理訂單、對照不同客戶的加工規格;如今宜展利用AI辨識訂單內容並匯入ERP,再依客戶、品項與規格進行標籤化派工。製程則透過QR Code記錄原料投入量與成品產出量,逐步掌握各環節的加工損耗。

接下來是整理現場的判斷依據。林佑澤透過與資深員工對談,了解採購、派工與品管的作業方式,再利用AI協助找出規則、建立SOP。AI整理出的流程仍須由現場人員逐項確認、修正,才能實際執行。

品質管理也在持續改善。傳統金屬檢測器難以辨識菜蟲、橡皮筋等非金屬異物,宜展正與技術夥伴規劃導入AI影像辨識,輔助產線末端檢查。林佑澤表示,每批農產品品質不同,比起單看良率,他更重視客訴是否減少。隨著訂單與製程資訊逐步累積,宜展也希望進一步建立需求預測、採購建議與生產排程模型,減少營運對資深員工個人經驗的依賴。

不只把菜切好,乾燥加工尋找第二成長曲線

除了改善截切本業,宜展也開始發展乾燥加工。學校團膳在寒暑假面臨需求波動,生鮮蔬果則有保存期限短、價格易受產季影響等限制。林佑澤希望藉由乾燥技術延長農產品保存期限,開拓附加價值更高的加工業務。

不過,乾燥同樣有依賴經驗的問題。傳統做法是太乾就降低溫度、縮短時間,不夠乾就反向調整。每批原料的水分與成熟度不同,反覆試做不僅增加成本,也難以維持品質一致。「品質目標沒有設定的話,前面的製程參數就不知道怎麼調整。」林佑澤將過去研發車用面板的思維帶進農產加工:先決定產品希望達到的口感、含水率與水活性,再回頭檢視原料成熟度、截切厚度及乾燥參數等條件。

團隊進一步結合不同乾燥技術、自行改造設備,並接洽桃園的設備業者合作。林佑澤曾比較其他地區的設備,最後選擇設備構造、乾燥均勻度與可靠度較符合需求的桃園業者。宜展也持續累積製程參數,希望未來透過AI找出適合不同原料的乾燥曲線,減少反覆試做。

「我們主要還是要做代工,想要做一個功能性的原料平台。」林佑澤說,果乾目前更像是展示技術能力的產品,未來希望將服務延伸至辛香料、中藥材、太空食品、超級蔬菜及寵物食品等領域。現階段宜展主要營收仍來自蔬果截切本業,乾燥事業尚未形成主要收入。未來若能建立穩定的乾燥製程與代工能力,宜展便有機會從既有蔬果供應鏈,切入附加價值更高的食品原料市場。

從彰化走向桃園,驗證營運方法能否跨區複製

隨著加工流程逐步數位化,宜展也開始思考,這套管理方法能否帶到彰化以外的場域。

參與桃園市政府青年事務局天際線加速器及Meet桃園+後,宜展擴大與桃園產業生態系的連結。林佑澤提到,天際線協助邀集不同局處了解團隊需求,並提供資源媒合機會。宜展也開始與桃園市農會及在地農民合作,增加北部原料來源。這項合作不只拓展了供應來源,更成為宜展因應極端天候、穩定供貨的重要助力。林佑澤回憶,先前中南部連日降雨,蔬菜供應受到影響,宜展便從北部調度蔬菜,以不同產區互相支援,降低天候對供貨的衝擊。此外,團隊也透過天際線資源,獲得參與日本國際伴手禮設計競賽的輔導,並成功榮獲金賞獎肯定,除了展現產品的創新與設計實力,也為宜展拓展海外市場、提升國際能見度創造更多機會。

下一步,宜展規劃以桃園大溪作為第二個驗證場域,將彰化累積的資料、SOP與加工管理經驗,轉化為可複製、可優化的營運管理模式,帶到不同產地、供應鏈及人員條件下驗證。林佑澤指出,未來若要跨區域擴張,不可能每到一個新地方,就把原有團隊整批搬過去。因此,宜展希望將資深員工的實務經驗,轉化為標準化流程與數據模型,結合AI進行生產排程、資源配置及營運決策,讓新場域能依據當地條件快速調整,降低對特定人員經驗的依賴。

從彰化到桃園,宜展接下來要驗證的,是這套從傳統農產加工現場整理出來的管理方法,是能夠跨區域複製、快速部署並持續優化的農產加工營運系統。 長期目標是降低新場域的建置成本與管理複雜度,提升擴張效率,讓傳統農產加工業具備規模化發展的能力。

登入數位時代會員

開啟專屬自己的主題內容,

每日推播重點文章

閱讀會員專屬文章

請先登入數位時代會員

看更多獨享內容

請先登入數位時代會員

開啟收藏文章功能,

請先登入數位時代會員

開啟訂閱文章分類功能,

請先登入數位時代會員

我還不是會員, 註冊去!
追蹤我們
一次搞懂工業AI
© 2026 Business Next Media Corp. All Rights Reserved. 本網站內容未經允許,不得轉載。
106 台北市大安區光復南路102號9樓