導(dǎo)讀新年好！對我們很多人來說，2020年是艱難的一年，我們與COVID-19戰(zhàn)斗，并開啟了遠程辦公模式。這一年，因為我們所有人只能呆在自己家里，幾乎沒有去旅行，....

新年好！

對我們很多人來說，2020 年是艱難的一年，我們與 COVID-19 戰(zhàn)斗，并開啟了遠程辦公模式。這一年，因為我們所有人只能呆在自己家里，幾乎沒有去旅行，所以我們有了大把的時間。我們認為理所當然的東西被奪走了，我們擔憂會失去親人朋友。希望 2021 年，我們能自由地生活。但現(xiàn)在更需要我們的責任感和警惕性。

在現(xiàn)在的公司，我擔任首席技術(shù)官（CTO）已經(jīng)有一年有余。值此歲末之際，對我這一年的工作做簡單總結(jié)。回顧這一年的歷程，過程很艱難，收獲也很大。有些時候，我會認為我不具有領(lǐng)導(dǎo)能力，應(yīng)該回去做一個個人貢獻者。但是，非常感謝公司對我的支持以及我個人的學習(書籍、博客、觀察)，我開始享受這個角色，并直面它帶來的挑戰(zhàn)。

在談?wù)撐耀@得的經(jīng)驗教訓之前，先回顧下我的軟件工程師職業(yè)生涯。

我的軟件工程師職業(yè)生涯

• 2005——2008：軟件工程師
• 2008——2012：高級軟件工程師
• 2013——2014：首席技術(shù)專家
• 2014——2019：首席工程師/架構(gòu)師（在此期間，我的角色是總監(jiān)，但我仍然會花很多精力在代碼編寫、系統(tǒng)構(gòu)建和技術(shù)咨詢方面)
• 2020——至今： 首席技術(shù)官（我的第一個領(lǐng)導(dǎo)/管理職位）

這是我第一次擔任領(lǐng)導(dǎo)和管理職務(wù)。從個人貢獻者到首席技術(shù)官的轉(zhuǎn)變不僅意味著壓力變大，責任也變大了。

這次轉(zhuǎn)變帶來機遇的同時，也讓我面臨很大挑戰(zhàn)。盡管如此，我還是冒險開始，并摸著石頭過河。

何為 CTO？

當知道我將成為下一任 CTO 時，我的第一個想法是找一份指導(dǎo)手冊，看看 CTO 要做什么，以及怎么做才能成為一名優(yōu)秀的、成功的 CTO。我想為這個角色做好準備，于是去研究了網(wǎng)絡(luò)上我能找到的所有與 CTO 相關(guān)的文章。你猜怎么著？這種指導(dǎo)手冊壓根就不存在。

直到今日，我仍然只能在工作中學習并確保同樣的錯誤不要犯第二次。

我想知道的第一件事是首席技術(shù)官（CTO）的定義是什么。顯然，這是最難以說清的首席類角色之一，每個 CTO 扮演的角色都稍有不同。對這個角色最好的描述我是在馬特·塔克（Matt Tucker）的一篇文章中看到的。根據(jù) Matt 的說法，CTO 角色由五個特征組成。

馬特·塔克的 CTO 框架表格

我認為上述框架為我們理解 CTO 角色提供了一個很好的思維模型。大多數(shù)情況下，CTO 是上述兩種或兩種以上特征的組合。

介紹一下我的 CTO 職責。Matt Tucker 框架描述的 CTO 是產(chǎn)品研發(fā)公司的 CTO。我是一家提供 IT 服務(wù)公司的 CTO，因為下面的一些原因，這類職位更加碎片化和更具挑戰(zhàn)性：

• 在任何組織中，人都是重要的資產(chǎn)。對于提供 IT 服務(wù)的公司來說，業(yè)務(wù)增長率與人員數(shù)量成正比。但如果你想成為好的服務(wù)提供商，情況就有所不同了。
• 你必須讓那些還沒有準備好應(yīng)對變化的大型企業(yè)能成功應(yīng)用先進技術(shù)。在過去 5 年中，大多數(shù)組織都在進行數(shù)字化轉(zhuǎn)型。以我的經(jīng)驗來看，現(xiàn)階段的組織比以往任何時候都更愿意嘗試新的技術(shù)（React、Golang、Flutter、Cloud、Kubernetes）和架構(gòu)風格（微服務(wù)、事件驅(qū)動、無服務(wù)器）。這是一個好消息，但是，很少有組織能理解采用先進技術(shù)棧要付出的代價。他們想成為他們行業(yè)領(lǐng)域的 Google，但基礎(chǔ)工作做得并不夠。這個在我的文章《使用微服務(wù)會失敗的11個原因》中有所提及。
• 在先進技術(shù)領(lǐng)域，真正有經(jīng)驗的優(yōu)秀軟件工程師并不多。好的軟件工程師都很昂貴，而且他們更傾向于去產(chǎn)品研發(fā)公司。作為 IT 服務(wù)公司，很難給出產(chǎn)品研發(fā)公司相同的薪水。

介紹 IT 服務(wù)組織 CTO 的文章并不多，也沒有明確誰是你遵循的榜樣，下面我將在 Matt 框架的基礎(chǔ)上，結(jié)合自身情況，給出我對 IT 服務(wù)組織 CTO 的理解。

這是我結(jié)合自身情況對 Matt 框架做的修改，并且對于去年我在各部分花費的時間給出粗略的估計 。

修改后的 CTO 框架

正如你在上述表格中看到的，我無處不在。幸運的是，我在不同任務(wù)間切換所消耗的精力較少，這主要是因為同一時間我參與的任務(wù)不會超過兩個。

在我擔任 CTO 的這一年時間中，我建立了一套任務(wù)授權(quán)體系架構(gòu)。希望在第二年，我能更專注于做一些重要的事情。

第一年學到的經(jīng)驗教訓

到目前為止，我分享了我的職業(yè)經(jīng)歷和對 CTO 角色的理解。下面我將和你一起回顧下這一年中的經(jīng)驗教訓。

1.相信自己并積極爭取

很多軟件工程師都夢想有一天能成為 CTO，這被很多人視為軟件工程師職業(yè)生涯的頂點。但是，公司并不會僅僅因為你是最有能力的軟件工程師/架構(gòu)師，就任命你為 CTO。你需要自己去爭取。

我花了 2-3 年的時間去為 CTO 這個職位做準備。讓我一直有所顧慮的原因之一是彼得原理。

彼得原理是一種經(jīng)驗理論，即在各種組織中，如一個公司，由于習慣于對在某個等級上稱職的人員進行晉升提拔 ，因而雇員總是趨向于被晉升到其不稱職的地位。

我一直以豐富的軟件開發(fā)和架構(gòu)經(jīng)驗而自豪。擔心自己有一天會跟不上技術(shù)發(fā)展的腳步，所以我一直向著技術(shù)專家的方向努力，而非向管理方向發(fā)展。

后來，我想通了，如果我不競爭這個職位，其他人就會。我的優(yōu)勢是對公司有足夠多的了解，并且具有領(lǐng)導(dǎo)能力，所以為什么不試一下呢？ 對我來說，最困難繁榮是主動爭取。可悲的是，如果你不主動爭取，別人就不會給你。

我發(fā)現(xiàn)了一個規(guī)律，大多數(shù)人因為羞于開口而錯失很多良機。一直以來，我從沒有碰到過不愿幫助自己的人，只要我開口，基本上沒有人會拒絕我。——史蒂夫·喬布斯

2.合理規(guī)劃時間

幾周前，一位同事問我， 在參加這么多會議的情況下，你還能完成需要投入較多精力的工作嗎？我發(fā)現(xiàn)，一旦人們發(fā)現(xiàn)我在會議時間段沒有安排，他們就會讓我參加會議。在 2020 年上半年期間，我一直在會議的泥潭中掙扎，一天中大部分時間都在開會。在這段時間里，大部分需要思考的工作我只能在下班或周末完成。

下半年，在意識到需要對時間有自己的規(guī)劃后，我改變了工作方式。現(xiàn)在，我每天會抽出幾小時，甚至半天時間，專注于一些需要全身心投入的工作。這樣，我就能夠在制造者日程表（maker schedule）和管理者日程表（manager schedule）之間自如地切換。

另一方面，我也避免成為日程表的奴隸。我采用的方法是，和會議組織者確認是否有必要參加。其他情況下，如果有我團隊的人已經(jīng)參加會議，我就不參加了。

3.凡事不必親力親為

大多數(shù)新晉的管理者都會面臨這個挑戰(zhàn)。你知道這個任務(wù)自己可以做得又快又好，所以傾向于自己完成任務(wù)。但是這無法發(fā)揮團隊的力量，你很快就會成為團隊的瓶頸。

發(fā)揮團隊力量的最好方式是充分授權(quán)。包含兩個方面：授權(quán)什么和授權(quán)到什么地步。

授權(quán)什么

確定哪些任務(wù)需要授權(quán)，珍妮·布萊克（Jenny Blake）將任務(wù)分為 6 類，她稱之為 6T。

• 瑣碎任務(wù)（Tiny）：非常小的任務(wù)，看起來不重要，但會慢慢累積。
• 無聊的任務(wù)（Tedious）：相對簡單的任務(wù)，利用瑣碎時間完成。
• 耗時的工作（Time-consuming）：雖然這些任務(wù)可能很重要、有點復(fù)雜、需要花費時間，但最初的 80%的研究工作并不需要你做。
• 可指導(dǎo)的任務(wù)（Teachable）：乍一看很復(fù)雜，但可以被分成幾個子任務(wù)的任務(wù)。這類任務(wù)可以分配后交給團隊成員去做，你只要做好質(zhì)量檢查和最終裁判即可。
• 不擅長的工作（Terrible At）：不僅不是你的強項，而且也是你不想干的。
• 有期限的工作（Time-Sensitive）：當你手頭有其他任務(wù)，而且沒法在截止日期完成所有的任務(wù)，你需要把某些重要且有明確時間要求的任務(wù)分派出去，從而保證所有任務(wù)能在截止時間內(nèi)完成。

像組織內(nèi)部技術(shù)會議、辦公網(wǎng)絡(luò)環(huán)境的維護、代碼審查、招聘初級工程師等任務(wù)，我都分派給其他人去做。

當你清楚了哪些任務(wù)需要分配后，接下來需要考慮的是分配級別。你需要明白按什么級別分配任務(wù)以保證任務(wù)能 100%完成 。我在網(wǎng)站“管理 30“中學到了 7 層分配級別。

• 告訴（Tell）：分配任務(wù)，并告訴下屬一步步怎么做
• 轉(zhuǎn)交（Sell）：我先做一部分，再移交給他們
• 顧問（Consult）：我作為顧問，并做出決策
• 協(xié)商（Agree）：我們一起做出決策
• 建議（Advise）：我給出建議，他們來決策
• 詢問（Inquire）：他們決策后我詢問結(jié)果
• 分派（Delegate）：只分配任務(wù)

到最后，你需要使用足夠的管理手段來確保事情按計劃進行。

4.減少混亂

不管你喜不喜歡，每個組織都會有混亂發(fā)生。混亂可能是軟件交付出錯、導(dǎo)致客戶系統(tǒng)掛了的要命 bug、系統(tǒng)性能問題或者和人相關(guān)的問題。當你作為領(lǐng)導(dǎo)參加這樣的會議時，人們期望在會議結(jié)束時，事情變得清晰，團隊有一個可執(zhí)行的計劃。

作為領(lǐng)導(dǎo)者，你的工作就是減少混亂，讓事情變得清晰。下面是我經(jīng)常使用的減少混亂的操作步驟：

• 通過問問題來讓事情變得清晰。這樣可以去除不重要的信息直達問題的核心。作為領(lǐng)導(dǎo)者，你的目標是引導(dǎo)人們思考。所以，你需要問一些深刻而寬泛的問題，如你為什么選擇這種設(shè)計？這個度量指標能告訴我們什么？現(xiàn)在用戶在想什么？
• 創(chuàng)建一個小的、清晰的 todo 清單。例如，這是一個修復(fù)性能問題的 todo 清單：
• 觀察 APM 工具中的性能指標，找到問題原因
• 在模擬環(huán)境重現(xiàn)問題
• 看看需要性能調(diào)優(yōu)的單元是否存在對應(yīng)的測試，如果沒有，就編寫測試
• 修正問題并保證單元測試通過
• 部署到更底層的環(huán)境并觀察補丁的效果
• 發(fā)布到生產(chǎn)環(huán)境
• 觀察 APM 性能指標確認問題已解決
• 將任務(wù)分配給負責人
• 在 wiki 上做記錄

我發(fā)現(xiàn)另一件有趣的事情是，許多人無法靠抽象概念來開展工作。一旦有人在任務(wù)上開了個頭，很多人就知道該怎么做了，你需要將事情分解成可操作的具體步驟。這意味著在你將任務(wù)移交給其他人前，你需要進行大量的思考。作為一名領(lǐng)導(dǎo)者，隨著時間的推移，你會明白不同類型的任務(wù)，在開始之前需要思考到什么程度。

5.你有時候需要表現(xiàn)出不滿

作為一個領(lǐng)導(dǎo)者，你不應(yīng)該感情用事。我同意領(lǐng)導(dǎo)者在 90%的情況下都不應(yīng)該。但是，有些時候你需要表現(xiàn)出你對事情的不滿。你不滿的警戒值應(yīng)該很高，不應(yīng)該經(jīng)常達到。如果有人把事情搞砸了，你必須做出反應(yīng)。

舉個例子，有一次，一位高級開發(fā)人員（接近 10 年的開發(fā)經(jīng)驗）在團隊群里發(fā)了一條消息，說他們從昨天就被卡住了，一個 REST API Java 客戶端不能調(diào)用，但 Postman（一個 API 調(diào)試程序）可以。這個問題很奇怪，所以我和團隊成員一起開會來研究這個問題。這位開發(fā)人員先是展示了 Postman 的調(diào)用情況，然后是 Java 代碼。最終找到的原因是 JSON 格式的請求參數(shù)中有一個應(yīng)該是 username，但 java 程序傳遞的是 userId，在 Postman 中傳的是 username，所以可以工作。

我知道這件事微不足道，很多開發(fā)人員可能會犯同樣的錯誤。但令我失望的原因是：如果 Postman 可以工作，而你的代碼不能，你不應(yīng)該在不檢查代碼的情況下就認定 API 有問題。你不能在一天什么也沒干的情況下，在第二天的站會（standup）上告訴客戶其他人寫的 API 有問題，客戶可沒那么寬容。有一些自動生成 REST 客戶端的工具（如 Insomnia）可以幫你驗證假設(shè)。

我這里提到的表現(xiàn)出不滿并不是要責罵某人。只是意味著你需要表明期望，讓他們知道你希望他們把事情弄清楚。同時，教他們調(diào)試這類問題的方法。

同樣的，也有其他情況下，你需要表現(xiàn)出不滿，但正如我所說，你的警戒線應(yīng)該更高，這樣的情況不應(yīng)該經(jīng)常發(fā)生。

6.從其他人的錯誤中學習

經(jīng)常聽到有人說應(yīng)該從自己的失敗中吸取教訓。

如果你善于觀察，就能從別人的失敗中學習，從而減少自己的失敗。換句話說，你可以從別人身上學到經(jīng)驗教訓。這是非常有用的技能，而且它能幫你更快地達到目標。

但是，它要求你仔細地觀察其他人，了解他們的特點和他們失敗的背景。一旦你了解了這些人，知道了他們失敗的原因，你就能夠避免犯同樣的錯誤。在組織中，多個領(lǐng)導(dǎo)都試圖做出同樣的改變，這很常見。理解前任領(lǐng)導(dǎo)為什么失敗，可以幫助現(xiàn)任領(lǐng)導(dǎo)更容易實現(xiàn)成功。

7.你不可能有所有答案，這沒什么大不了的

我給自己施加了很大壓力，為所有問題都提供答案。我調(diào)試錯誤，考慮問題的解決方案，并為別人做大量的研究工作。

我越努力解決問題，別人給我的問題就越多。我原以為人們會學著面對自己的問題。但是，人們更愿意從我這里得到完整的答案。

我意識到部分原因是我處理問題的方式有問題。我想成為一個無所不知的好領(lǐng)導(dǎo)。我們都知道這是不可能的，但當你成為一個領(lǐng)導(dǎo)者，就有這種成為英雄的傾向。所以，我改變了方法。我開始給人們一個谷歌文檔模板，他們需要先填寫，然后我才會與他們一起解決問題。這份文檔需要他們寫明 ：問題的定義、對問題的理解，做了哪些嘗試以及哪些沒有成功。

于是產(chǎn)生了三種結(jié)果：有一些問題，他們真的不能解決；我參與并給出建議，他們作為負責人解決問題；一些問題沒有回音了（我認為他們寫文檔的過程中，把問題解決了）。

作為領(lǐng)導(dǎo)者，你的工作不是為人們尋找答案，而是幫助他們找到答案。說我不知道，讓別人承擔責任，是成熟領(lǐng)導(dǎo)的標志。

8.你培養(yǎng)的人有可能離職

在過去幾年中，我雇傭了很多有潛力的工程師。我和他們結(jié)對編程，指導(dǎo)他們，給他們機會。但是，他們后來離職了。對很多優(yōu)秀的工程師來說，產(chǎn)品研發(fā)公司才是他們夢想的工作。這很無奈，但卻是事實。

有時候，我甚至認為一個好的 IT 服務(wù)機構(gòu)，其工作之一就是為產(chǎn)品研發(fā)公司培養(yǎng)工程師。

我認為以下是工程師想加入產(chǎn)品研發(fā)公司的原因：

• 他們希望有一天能創(chuàng)立自己的公司，而在產(chǎn)品研發(fā)公司工作能學到很多東西。
• 很少需要在不同的工程間切換。你可以在一個團隊工作很多年。
• 你可以在某個領(lǐng)域持續(xù)鉆研。
• 產(chǎn)品研發(fā)公司比 IT 服務(wù)組織工資高。

到目前為止，在我的職業(yè)生涯中，我主要是在 IT 服務(wù)機構(gòu)工作。我認為在 IT 服務(wù)機構(gòu)工作有一個好處是：

您可以在很短的時間內(nèi)在多種技術(shù)和多個領(lǐng)域間都有所涉獵。我開發(fā)過 DevOps 工具、實時定價引擎、多租戶 SaaS 應(yīng)用系統(tǒng)、社交平臺、幫助銀行進行數(shù)字化轉(zhuǎn)型（架構(gòu)、DevOps 實踐）等等。

9.可以編程，但不要做出承諾

如果你在網(wǎng)上讀到討論技術(shù)經(jīng)理或者 CTO 是否應(yīng)該編程的問題，你會發(fā)現(xiàn)很多人都反對編程。反對編程的兩個理由是：

• 你有很多更重要的事情，而編程并不在其中。你可能不能及時完成任務(wù)，而這會拖累你的團隊。
• 屈服于“對編程的愛”的危險在于，在追逐“令人驚嘆”技術(shù)的欲望之下，會漸漸遺忘你的業(yè)務(wù)目標。

在我擔任 CTO 的第一年中，我與交付團隊一起工作，交付代碼。這是在三個重要項目中我做的工作：

• 向交付團隊明確我不是任務(wù)的負責人。如果我的時間允許，我會交付代碼，但他們不能指望每次我都能按時完成。這意味著除我之外，每個項目都應(yīng)該有一個技術(shù)負責人。
• 以防我沒空，我總是和一個能推進任務(wù)的團隊成員結(jié)對編程。
• 通過審查代碼和工程設(shè)計文檔而不是編寫代碼來貢獻價值
• 優(yōu)先為被困的人排憂解難。

我喜歡編程。為了編程技能不至于荒廢，下班后我會參與項目。

10.只有很少的客戶看中質(zhì)量

很多客戶希望他們的供應(yīng)商能夠提供：

1. 一個高質(zhì)量的產(chǎn)品
2. 敏捷需求管理
3. 在約定的時間和費用內(nèi)完成交付

我們都知道，構(gòu)建滿足這三個條件的產(chǎn)品是很困難的。

在這些條件中，當團隊面臨時間和成本壓力時，質(zhì)量是首先被犧牲的。質(zhì)量需要花費時間和金錢，與功能相比，它的優(yōu)先級并不高。

客戶以為軟件是以工廠模式交付的，在這種模式下，團隊人數(shù)越多，功能開發(fā)越快。根據(jù)我的經(jīng)驗，按照工廠模式交付軟件是有問題的，你并不能使用這個模式構(gòu)建好的產(chǎn)品。

11.我喜歡你，但不會向著你說話

在我擔任首席技術(shù)官的第一年里，這種情況發(fā)生過很多次，如果你和某人工作關(guān)系很好，他就希望你能向著他說話。

我意識到，職位越高就越孤獨。在人際關(guān)系和工作關(guān)系間保持平衡是很困難的。當你和一個人關(guān)系好時，你很難在不傷害他的情況下質(zhì)疑他。

12.聰明地選擇要參加的戰(zhàn)斗

我意識到只有少數(shù)問題是值得我解決的。去解決所有的問題，這只是你的美好愿望。我在卡米爾·弗爾涅（Camille Fournier）的文章中發(fā)現(xiàn)了這個流程圖，它提供了一個很好的框架來幫助你選擇要參加哪一場戰(zhàn)斗。

13.持續(xù)推進事情

這是作為領(lǐng)導(dǎo)者應(yīng)該牢記的重要教訓。你不應(yīng)該成為系統(tǒng)中的瓶頸。有兩種情況，你會成為瓶頸：

1. 停下系統(tǒng)并試圖一次性修復(fù)它。這行不通。最終你會把自己壓得喘不過氣來，并且反對的聲音會越來越多。你必須以一種小確幸的方式來做——朝著你的最終目標，每次只做一小步。你甚至不需要告訴別人你的最終目標。保持小的戰(zhàn)術(shù)改變，并牢記大的戰(zhàn)略目標。
2. 不要太快做出決定。如果你還沒習慣做出的決定會影響到其他人，當你處于這種情況下，你會感到壓力和不知所措。很多人都希望把決定推出去而自己一點都不要碰。作為領(lǐng)導(dǎo)者，你必須明白不是所有的決定都是一樣的，不做決定也是一種決定。我喜歡杰夫·貝佐斯(Jeff Bezos)，他是亞馬遜決策心理模型(mental model on decision making)的創(chuàng)立者。他說，你應(yīng)該問問自己，這個決定是可逆的還是不可逆的。

有些決定是順序的、不可逆轉(zhuǎn)的或幾乎不可逆轉(zhuǎn)的——這是一扇單向的門——這些決定你必須有條理、仔細思考后、緩慢地做出，并經(jīng)過大量的審議和協(xié)商。

如果你推開門走出去，不喜歡你在另一邊看到的風景，卻無法回到原來的地方。我們稱之為第一類決策。但很多決定不是這樣的——它們是可變的、可逆的——它們是雙向的門，這是第二類決策。

對于第二類決策，如果你的決定不是最好的，你不需要承受太長時間的后果。你可以再次打開門，重新再來。第二類決策應(yīng)該由高判斷力的個人或小團體迅速做出。

事實證明，我們做出的大多數(shù)決定都是可以逆轉(zhuǎn)的。這樣我們就能快速地做出決定，推動事物向前發(fā)展。

14.你說的話會影響其他人，你需要承擔責任

不要讓別人強迫你做你不認同的決定。他們之后可能會追究你的責任，并且他們的做法是對的。做出決定需要承擔責任。

原文鏈接：

https://shekhargulati.com/2021/01/03/being-chief-technology-officer-lessons-learned-in-my-first-year/

延伸閱讀：

干了6年軟件開發(fā)，我的那些變與不變的想法-InfoQ

關(guān)注我并轉(zhuǎn)發(fā)此篇文章，即可獲得學習資料~若想了解更多，也可移步InfoQ官網(wǎng)，獲取InfoQ最新資訊～