作為科技界廣受贊譽(yù)的杰出管理人才，前百度集團(tuán)總裁、Y Combinator 中國創(chuàng)始人陸奇在接受媒體采訪時(shí)，曾談到管理具備穿透力的關(guān)鍵在于自己要有相應(yīng)的專業(yè)能力，“我以前要求自己做到的是，我手下兩層以下的人，他們每個(gè)人的工作我都能做。這樣整個(gè)公司里，沒有人敢欺騙你、忽悠你。這個(gè)非常重要，大部分企業(yè)中層都在忽悠高層，資源其實(shí)是浪費(fèi)掉的。” 在陸奇的邏輯里，管理人員至少要能隨時(shí)接管比自己低二個(gè)級別的人手上的工作，這就要求管理人員必須是專家中的專家，清楚工作的每一個(gè)細(xì)節(jié)。也就是說，一個(gè)真正強(qiáng)大的管理者，是絕對不應(yīng)該憑借所謂“管理能力”做到領(lǐng)導(dǎo)的，特別是技術(shù)管理人員，有代碼實(shí)操能力，保持對一線業(yè)務(wù)敏感，也是優(yōu)秀領(lǐng)導(dǎo)者要具備的能力。 然而對于“IT 領(lǐng)導(dǎo)者應(yīng)該是位出色的工程師”、“CTO/VPE（工程副總裁）應(yīng)該具備怎樣的技術(shù)水平”這一類的話題，總是存在一些爭議。 乍看之下，很多人可能覺得這問題有點(diǎn)莫名其妙——首席技術(shù)官和工程副總裁不都是技術(shù)人嗎，沒兩把刷子還能當(dāng)技術(shù)主管？但實(shí)際情況就是有不少 CTO/VPE 雖然在自己的崗位上做得相當(dāng)出色，但技術(shù)水平卻不是很突出。 這也是很多科技企業(yè)領(lǐng)導(dǎo)班子的一個(gè)奇怪之處。工程團(tuán)隊(duì)在每個(gè)成長階段都會(huì)建立起新的管理層，把負(fù)責(zé)人從實(shí)際技術(shù)工作中抽離出來。這種制度的問題是一方面強(qiáng)行要求優(yōu)秀的員工在管理和技術(shù)中二選其一，另一方面迫使很多技術(shù)超強(qiáng)但管理思維不足的候選人因未能晉升而失望離職。 馬斯克在今年也曾發(fā)布一條 Twitter，表示深信技術(shù)領(lǐng)域的管理者必須具備優(yōu)秀的技術(shù)能力，領(lǐng)導(dǎo)軟件開發(fā)的人也需擅長寫代碼。這個(gè)說法深受一線開發(fā)人員贊同，但馬斯克照樣也收到了一些管理者的強(qiáng)烈反對，評論中有人認(rèn)為管理能力和技術(shù)能力不是一回事兒，一個(gè)人是不可能同時(shí)掌握好這兩種能力的......  最近，又一篇評論“CTO，也該是技術(shù)人”的文章在 Hacker News 上被頂上了“熱搜”。  作者 Aditya Agarwal 與馬斯克的觀點(diǎn)很一致，認(rèn)為技術(shù)管理者必須具備過硬的技術(shù)能力，甚至是代碼能力。 Aditya Agarwal 擁有卡內(nèi)基梅隆大學(xué)的計(jì)算機(jī)科學(xué)學(xué)士和碩士學(xué)位，是 Facebook 的首批工程師之一，他幫助構(gòu)建了 Search、NewsFeed 和 Messenger 等關(guān)鍵產(chǎn)品的第一個(gè)版本，隨后成為 Facebook 的第一任產(chǎn)品工程總監(jiān)。也曾作為 Dropbox 的首席技術(shù)官和工程副總裁，將 Dropbox 工程團(tuán)隊(duì)從 25 人擴(kuò)大到 1000 人，領(lǐng)導(dǎo)并負(fù)責(zé) Dropbox 新產(chǎn)品開發(fā)、基礎(chǔ)設(shè)施和技術(shù)運(yùn)營多個(gè)方面的工作。另外他也是硅谷初創(chuàng)公司的投資者和顧問，是一家籌集了 5000 萬美元種子風(fēng)險(xiǎn)基金的創(chuàng)投企業(yè)合伙人。 在文章中，他表示領(lǐng)導(dǎo)者的技術(shù)水平與員工水平是直接掛鉤的，并以跟蹤和解決 bug 為例，講解了深厚的技術(shù)能力如何成就卓越的工程領(lǐng)導(dǎo)者形象。 同樣的，他的觀點(diǎn)激起了很多討論，包含一線研發(fā)和 CTO，尤其對于解決 bug 這種能力，大家非常有分歧。 一些持贊成意見的講道：
一些持反對意見：
...... 我們將 Aditya Agarwal 的文章翻譯了出來，如果你有類似的經(jīng)歷和自己的看法，歡迎留言評論： CTO 必須是技術(shù)高手嗎？CTO 需要在項(xiàng)目沖刺階段參與開發(fā)，跟同事們一道加班加點(diǎn)寫完代碼嗎？他們有必要扮演系統(tǒng)“首席架構(gòu)師”的角色嗎？VPE 要不要擁有出色的技術(shù)洞察力？或者說，在這樣一個(gè)以管人為主的崗位上，其實(shí)沒必要對技術(shù)和技能提出過高的要求？ 其實(shí)是應(yīng)該有所要求的。企業(yè)技術(shù)高管應(yīng)該保持自己技術(shù)水準(zhǔn)的主要原因，有以下五點(diǎn)：
與 Bug 的永恒之戰(zhàn)下面我們從具體整合出發(fā)，聊聊在與 bug 的永恒之戰(zhàn)中，深厚的技術(shù)能力如何成就卓越的工程領(lǐng)導(dǎo)者形象。 任何軟件都永遠(yuǎn)擺脫不掉 bug 的陰影，殘酷的現(xiàn)實(shí)就是如此。這種對抗可以膠著、可以緩和，但永遠(yuǎn)不可能徹底勝利。而企業(yè)中工程領(lǐng)導(dǎo)者的一大責(zé)任就是在開發(fā)新功能（大家都愛新功能）跟維持質(zhì)量/消除 bug 之間找到平衡點(diǎn)。也就是說，技術(shù)領(lǐng)導(dǎo)者必須以截然不同的激勵(lì)措施分別面對產(chǎn)品與銷售團(tuán)隊(duì)間的需求沖突。 首先要明確一點(diǎn)，如果無法衡量、則無法改進(jìn)。因此，針對 bug 的第一階段作戰(zhàn)計(jì)劃就是先衡量現(xiàn)有產(chǎn)品的質(zhì)量是什么水平。如果非要說，還有個(gè)第零階段，就是定義什么是質(zhì)量“好”。 這就要回答一個(gè)產(chǎn)品層面的問題：在我們的應(yīng)用程序當(dāng)中，用戶最關(guān)注的前兩、三項(xiàng)指標(biāo)是什么？最終得出的答案，就是我們必須全力保障、使其始終正常運(yùn)行的核心。 以 Dropbox 為例，這家公司的宗旨就是存儲(chǔ)在平臺(tái)上的用戶數(shù)據(jù)永遠(yuǎn)不會(huì)丟失或損壞。畢竟任何數(shù)據(jù)訪問故障都會(huì)破壞 Dropbox 這個(gè)品牌的核心價(jià)值。作為存儲(chǔ)服務(wù)商，Dropbox 只要弄丟一個(gè)文件，供需雙方間的信任將徹底消失。其他的當(dāng)然也很重要，但這種可靠性永遠(yuǎn)是第一位。 在 Facebook，衡量質(zhì)量的關(guān)鍵是保證在應(yīng)許的地域和不同網(wǎng)絡(luò)條件下始終提供快速穩(wěn)定的頁面/應(yīng)用程序加載速度。如果無法快速瀏覽 Facebook 頁面，很多用戶就會(huì)失掉耐心、選擇退出。 第零階段討論完成：為產(chǎn)品制定清晰的、包含上下文信息的質(zhì)量定義。 正式進(jìn)入第一階段，通過這項(xiàng)定義做出準(zhǔn)確衡量。這事聽起來容易，但也不可能一蹴而就。雖然市面上已經(jīng)有很多優(yōu)秀的數(shù)據(jù)工具，但根據(jù)個(gè)人經(jīng)驗(yàn)，正確的內(nèi)容配置和設(shè)定還是需要漫長的探索和調(diào)整。最初難免要出點(diǎn)錯(cuò)誤（例如低質(zhì)量數(shù)據(jù)），但請千萬堅(jiān)持到底。 這里給大家分享一點(diǎn)具體建議，就是每周或每月組織一次質(zhì)量指標(biāo)審查，借此了解事情的發(fā)展趨勢。在此階段，我們唯一的目標(biāo)就是提高對衡量指標(biāo)的信心。 在建立起信心之后，接下來就要設(shè)置一條不可觸碰的質(zhì)量紅線。這就是第二階段，也是工程領(lǐng)導(dǎo)技術(shù)能力的集中體現(xiàn)。CTO/VPE 必須深入理解這條紅線該設(shè)置在哪里，逼近紅線時(shí)會(huì)出現(xiàn)哪些危險(xiǎn)信號，還有遠(yuǎn)離這條紅線需要做出哪些努力。 CTO 需要向團(tuán)隊(duì)成員明確表達(dá)：一旦質(zhì)量低于某個(gè)點(diǎn)，那么所有工作都要暫停，專注于將質(zhì)量拉回正軌。但這勢必會(huì)導(dǎo)致摩擦，特別是跟產(chǎn)品主管和 CEO 的摩擦。沒人喜歡開發(fā)延遲，我們更重視質(zhì)量，但他們可能更重視上市速度和投資回報(bào)。不過這就是技術(shù)主管必須貫徹的切實(shí)紀(jì)錄，而強(qiáng)大的技術(shù)能力可以讓我們的評估結(jié)果更受公司內(nèi)其他高管的信任，降低這項(xiàng)紀(jì)律的執(zhí)行門檻。 再來聊具體例子：隨著 Dropbox 工程團(tuán)隊(duì)的不斷壯大，加上對 Dropbox 桌面客戶端代碼庫的持續(xù)更改，我們發(fā)現(xiàn)的 bug 數(shù)量也在迅速增加。而考慮到大多數(shù)用戶都會(huì)通過桌面客戶端作為存儲(chǔ)文件的主要訪問方式，那這就是我們的服務(wù)紅線，絕對不能打破。 總是是，我們的桌面客戶端代碼庫并沒有隨著全體工程師的開發(fā)過程而擴(kuò)展。雖然一直能夠勉力維持，但深入研究技術(shù)架構(gòu)之后，我們發(fā)現(xiàn)原本的工作習(xí)慣離紅線太近了。我們最終得出結(jié)論，只有通過重建架構(gòu)，我們才能在穩(wěn)定支持后續(xù)擴(kuò)展的同時(shí)、讓 bug 修復(fù)變得更加輕松易行。唯一的問題，就是整個(gè)重構(gòu)過程大概需要 6 到 9 個(gè)月。 這時(shí)候，我們就要告訴 CEO，拿出時(shí)間投入到核心產(chǎn)品的根本性優(yōu)化當(dāng)中是必需的。把這部分延誤視為計(jì)劃內(nèi)部分，憑借出色的技術(shù)能力獲取公司領(lǐng)導(dǎo)層的信任，把握住推動(dòng)技術(shù)變革的主導(dǎo)權(quán)。 我承認(rèn)，速度對于初創(chuàng)企業(yè)至關(guān)重要。作為一名工程師，我在 Facebook 工作時(shí)就經(jīng)歷過快速行動(dòng)、打破常規(guī)的內(nèi)部變革時(shí)期。但 CTO/VPE 必須挺身而出，告訴大家什么叫“磨刀不誤砍柴工”，什么叫先慢下來才能全力沖刺。出色的技術(shù)能力不僅能讓我們自己對這一關(guān)鍵判斷更有信心，也能更好地感染并影響到企業(yè)內(nèi)的其他同事。 接下來就是 bug 之戰(zhàn)中的第三階段。在重建桌面客戶端架構(gòu)的過程中，我們在各個(gè)路線圖/OKR 規(guī)劃過程中不斷提高質(zhì)量標(biāo)準(zhǔn)，將紅線拔得更高，并隨著時(shí)間推移和實(shí)際情況持續(xù)調(diào)整產(chǎn)品質(zhì)量與紅線間的距離。 第三階段完成之后，我們就有了一個(gè)持久且穩(wěn)定的流程，能夠保證核心產(chǎn)品長治久安。 我聽說過不少 CTO/VPE 技術(shù)能力受到質(zhì)疑的情況，大多是因?yàn)檫@類高管職位要由企業(yè) CEO 和創(chuàng)始人親自面試，所以過程中往往缺少編程測試這個(gè)環(huán)節(jié)。 這里我簡單提一點(diǎn)：CTO/VPE/工程總監(jiān)至少得能通過編程測試，甚至應(yīng)該拿到一個(gè)很高的分?jǐn)?shù)。 當(dāng)然，候選人的管理技能、與創(chuàng)始人/同事們的合作能力和招聘能力也很重要，但他們也必須順利通過編程測試和詳盡的系統(tǒng)設(shè)計(jì)考察，畢竟這才是技術(shù)領(lǐng)導(dǎo)者的本分。 總而言之，首席技術(shù)官也應(yīng)該是技術(shù)人、必須是技術(shù)人。 參考鏈接： https://blog./your-cto-should-actually-be-technical/ https://news./item?id=32987094 https://news./post/4604869?level=1&data_ticket=1664251591162541 https://www.linkedin.com/in/adityaagarwal3/ |
|
|
