好的技術領導人頂得上100個工程師！

最新 05-27

大數據文摘作品

編譯：Zhifu、張文靜、王一丁、驚蟄、夏雅薇

一個優秀的技術領導不僅可以幫工程師的工作效率提高10倍，還能夠把自身的能量帶給團隊里每一個成員。那些幸運的工程師們在這些技術領導者的指導下不僅會發現自己事半功倍，而且可以體驗前所未有的系統化支持。

對你來說，工作是什麼？是養家糊口的工具，還是享受人生的方式？

而對於大多數工程師來說，想要把工作作為享受人生的方式，你需要有一個優秀的技術領導者。

技術領導者會擋掉所有無意義的「工作」，大大加快在有意義工作上的工作效率，從此整個團隊會變得無比和諧。

下面這篇文章來自於一名就職於Webflow的工程經理所撰寫的技術指導手冊，主要內容包括：

什麼叫做成功的技術領導者

當從純粹的技術角色轉型成混合管理和技術專長角色時外界對你的期望，以及如何管理這些期望

如何緩解一些常見的問題和挑戰

Webflow在管理上採取的辦法

這本手冊可以幫助所有勇於挑戰自我的領導在這樣一個把快樂與成功對立的世界裡享受對激情和成功的追求。

技術指導手冊鏈接：

https://github.com/webflow/leadership/blob/master/tech_lead.md

技術領導者到底是做什麼的？

根據其最基本的定義，技術主管「對項目的成功負有全部的責任，花費30%的時間編寫代碼，並利用剩餘的70%的時間管理項目」。技術領導者的目的就是指導一個才華洋溢的工程師團隊穿過波濤洶湧的水域，引導他們遠離危險，幫助他們清除障礙，並讓他們充分享受有意義的工作。

然而，說起來容易做起來難。

技術領導者需要無數的技能，不過最重要的幾個是真誠的同理心、清晰的溝通和卓越的技術。技術領導者是一個「混合」角色，一方面關注於管理，另一方面關注於工程，並且他們也是項目期望和任務開發之間的聯絡人。一個項目的成功取決於技術領導者，也取決於公司是否能夠確保他們充分獲得所需的支持。

為什麼我想成為一個技術領導者？

相比一般的工程師來說，技術領導者承受了更大的壓力，而且在平衡團隊管理和貢獻代碼的需求上是非常具有挑戰性的，特別是首次進入領導者角色的時候（順便說一句，這很正常）。

也就是說，管理者的生活非常有意義，他們在決策鏈上有更高地位，對於Webflow用戶的影響是至關重要的。在這個職位上，你會發展你的影響力，這提供了更多職業發展機會。這個角色經常被視為「高級」工程師的進階，也是工程經理職位的必要條件。你將指導並幫助其他工程師成長。有些人很享受這種新挑戰以推動他們個人到達新的高度。

我如何成為技術領導者？

儘管去問！是的，就是這麼簡單。向你的經理一對一地表明你有興趣成為技術主管。你的經理有責任為新角色設計一條路徑，並且根據你目前的經驗確定是否將你指定為下一個項目的技術主管——如果不是，則為你提供成為技術領導者所需技能的培訓機會。

當我管理團隊的時候外界對我有什麼期望？

技術領導者的工作包括如下的責任（排名不分先後）：

與產品經理緊密合作，在最後期限前後設置合理的期望，並明確在什麼情況下，項目被定義為難以按時完成

將項目分解成可完成的小任務，並將任務進展設置成迭代模式，保持跟進階段性進展

為團隊提供充足成塊的工作時間，以便讓他們能夠經常進入專心致志的工作狀態，並充當團隊的門衛，阻擋其他事去讓他們分心

確保你的團隊在任何時候都有足夠的工作，避免團隊成員處於想要工作卻無處可去的狀態

多做代碼審查，第一個去做質量檢查，並在必要時候自己也可以寫代碼

在團隊成員執行任務的時候盡量給他們機會與自己交流（合理估計有多少時間自己可以專心工作，有多少時間需要留給團隊做交流）

時不時與其他部門開展合作

案例鏈接：

https://github.com/webflow/leadership/blob/master/tech_lead.md#help-we-are-behind-schedule

技術主管可以管理哪些不同類型的團隊？

Webflow將其有才華的工程師安排到一個技術主管負責的（Action）和Permanent團隊。

行動團隊：在一個任務下組成，任務完成時解散

永久團隊：主攻一個主要問題且永不解散。如績效與穩定團隊。技術主管和隊員可以在這些團隊中輪崗。

我應該期望什麼規模的團隊？

每個團隊規模不盡相同（甚至可以有一個聯盟那麼多），但一般來說，團隊包括三名成員，其中包括技術主管。管理兩個人的團隊相對容易，但是一旦管理三個及以上的團隊，交流的可行性就會急劇下降。這並不僅僅是孤立技術主管的關係，而且也和團隊成員之間如何相互溝通有關。較大的團隊當然是可以工作的，但三人團隊是一個更好的起點。

這並不是說一個團隊只能有三名成員。一個行動小組可能包含七名成員，包括一名技術主管。技術主管可以將團隊分成兩組，並將每個小組的重點放在相似功能範圍的並行任務上。然後由技術主管決定每個團隊的團隊主管，並讓他們負責他們所在的團隊工作。請記住，每個小組都應該關注功能效率並彼此合作來解決問題，從而減少由於並行工作而經常產生的延遲。

前述的團隊結構可以由後端和前端工程師組成。Webflow希望模糊這些工程學科以及非工程學科之間的界限，例如設計師。形成跨學科團隊是功能效率的目標，無論是你個人的要求或項目的要求。

團隊效率和團隊管理

團隊設計有兩種方式。第一個是以「功能」效率來設計團隊，這個種方法有利於團隊合作來解決相關的問題，另一個方式是以「資源」效率來設計團隊，這種方式利於各成員來同時解決不同的問題。兩者都有自己的優勢，但我們要求技術主管儘可能地優化這兩種方式。

專業提示：並行化需要明確的範圍。如果你在帶領一個迭代設計規範的項目，那麼最好只是優化功能效率。

求助！我們的進程已經落後了！

保持平常心，去喝杯咖啡或晒晒太陽，再回到辦公桌前，心靜才能自然涼。

案例鏈接：

https://github.com/webflow/leadership/blob/master/tech_lead.md

幾乎每個項目都會遇到一些未知問題而影響交付日期。不要試圖去迴避這種情況，試著去接受。你需要將這些未知問題加到時間估算中，認識到遇到未知問題是很正常的。這是好與非常好的區別。

將沒有按時完成任務等同於罪責其實是士氣的殺手。士氣其實是你團隊最寶貴的資源。我們最好將「延後」理解為「進展推後」。Webflow理解軟體開發是艱難的，所以我們可以幫助你將不能如期交貨變為「進行中」的狀態。

關於項目管理

在我們深入研究「返工」「延期」「放棄」之前，有兩個重要的項目管理概念將幫助你理解為什麼要遵循這個期限。

首先，需要強調工作成果與固定日期聯繫起來的必要性。如果沒有明確的目標，進展很難衡量。我們必須衡量一些事情的進展，即使這只是一種猜測。進步是激勵的生命線。

其次，你可以通過四個指標來幫助項目回到正軌：

時間：工作成果的發時間

質量：工作成果的技術含量

資源：多少人參與了這項工作

範圍：這項工作是什麼以及是用來做什麼的

隨著項目的發展，這四個指標可能會發生變化。它們是項目經理有效管理的工具。也就是說，Webflow生產儘可能高質量的產品，但是不會犧牲時間，資源或範圍這另外三個槓桿，所以我們只需要使用這三個槓桿，下文會做進一步說明。

專業提示：技術主管通常是滿足企業需求的底線。他們的決定必須置於這樣的問題中：「如何保持公司健康成長？」。如果你的商業頭腦很少或根本沒有，你可以看看喬希考夫曼的「個人工商管理」。這是現代商業實踐中的精彩課程，可以幫助你在考慮Webflow的需求和團隊需求時做出更好的決策。

課程鏈接：

https://www.amazon.com/Personal-MBA-Master-Art-Business/dp/1591845572/ref=sr_1_1?s=books&ie=UTF8&qid=1513878441&sr=1-1&keywords=The+Personal+MBA）

返工/延期/放棄（緩解策略）

在與你的產品經理討論截止日期可能有變數時，你有三種選擇。在這裡按照考慮順序排序如下：

返工

延期

放棄項目

返工

返工應提出兩個問題：

我們能否為項目增加資源以如期交貨？

我們能否改變工作的範圍以如期交貨？

在評估如何避免錯過的期限時，質疑資源和範圍應該是第一個工具。首先考慮是否有更多的資源可以幫助解決這種情況，但通常情況並非如此，除非該項目最初人手不足。添加後期資源甚至會將截止日期推得更遠！所以，你的下一個工具是縮小範圍。

https://en.wikipedia.org/wiki/The_Mythical_Man-Month

專業提示：縮小範圍通常是在嘗試如期交貨的同時還能提供商業價值的首選。項目需要更多資源才能如期交貨的可能性在10％的範圍內，90％的可能性為縮小範圍。

縮小範圍通常是可行的。作為充滿激情的軟體開發人員，我們傾向於精鑽而不是粗放。這是你可以把工作切分成更切合實際的期望的小塊，並和利益相關者溝通這些實際的期望的機會。

延期

如果範圍不能縮小，並且增加資源也不是一種選擇，那麼下一個最好的選擇就是延後期限。

「那麼，如果期限是寬鬆的，那麼期限到底是什麼時候呢？」

呃，我們盡全力避免更改期限，但有時還是會發生，這其實是沒問題的。當我們試圖達到不切實際的期限時，會有太多的事情處於危險之中，其中包括團隊倦怠，產品質量差，士氣低落等等。

這裡的要強調的不是要忽視期限。關鍵是，如果不能按時交貨，項目將會陷入僵局，並且項目會向未知的方向發展。這比延期更糟糕，所以延期吧！

放棄

最後的和最少的選擇是完全放棄這個項目。如果你（或其他利益相關方）發現最後的成果會對公司產生負面影響。請考慮廢棄這個項目！注重高效工作，而不是生產性工作。

可選的第四種策略：緊盯項目進展

還有第四種選擇，即不能按時完成的威脅只不過是你內心的警鐘，那就需要密切關注這個項目。當你的直覺有威脅時，就要著重關注。走在問題的前面非常重要，而且這時可以先發制人。

專業提示：讓大家更輕鬆的關鍵是掌握管理期望的藝術。只要你保持坦誠，少說空話，多做實事是明智的。說實話，如實時表示對不能如期交貨或失去核心資源的擔憂；會比預期更早的完成工作可能性等。你要像你對未知事物持懷疑態度一樣誠實。

怎樣才能做出更好的估計？

在撰寫本文時，沒有人發現用於預測軟體開發時間表的魔法。其實軟體評估很少準確。這是敏捷哲學的核心：迭代和發現，然後交貨和改進。這是一種發現的藝術，而不是交付的藝術。

Webflow遵循一個迭代過程，如其他部分所述，預估是重要的，但沒有揭示未知問題那麼重要。

迭代過程鏈接：

https://github.com/webflow/leadership/blob/master/tech_lead.md

這裡有一些幫助準確預估的策略：

預估未知

發展很少按計劃展開。你可以給任務最佳猜測，但不是精準預估。把最佳猜測的時間乘以四倍，特別是如果該任務涉及未知問題。這聽起來有點瘋狂，但是有時候是需要這樣的。當然經驗有助於技術主管改進這個方程式，但這是一個很好的起點，為未知數留下解決空間。

疊加未知

一旦你創建了你的主要追蹤問題，你可以大概了解項目可能需要多長時間。一定要確定哪些任務與發現未知問題相關，哪些具有更多具體的方案。發現所有未知問題後，你將對交貨日期的準確性有更好的理解。

二八原則

我們很容易忽略時間消耗的細微差別，從而減緩項目的最後20％的完成。當全面地查看項目時，請使用80/20規則將其分解。項目的最後20％可能占整個時間軸的80%。造成這種情況的原因有很多，但最後的20％往往是對工作成果進行完善，完善每一個功能和每一個角落上很複雜的，這些情況在項目結束時會出現重合。

這就意味著只要將項目中的前80%當做還是在途中。這將使預期與項目後續需要的精細度相符。

永遠不要忘記測試！

當你預估截止日期時，記得要為代碼完成選定一個日期，以便QA有時間來發現錯誤或未解決問題。預估時間這中必須考慮進這個「檢驗」時間，同時也應考慮QA目前的工作量。

冷卻：錯誤修復後交付

在交付時，應該計劃留出一些時間，在開始新的里程碑之前解決任何即時錯誤。時間的長短可能因可交付成果的複雜程度而異，一般選擇一周為一個時間節點。這是一個讓你的團隊在進入下一組任務之前休息休息的機會，同時也有助於收緊下一個里程碑的MTI。

項目需要多長時間？

雖然功能的範圍可能需要數月和數月的工作，但其版本里程碑的目標應該是六周的時間表，包括質量保證，因此每個裡程碑的代碼都是在四周左右完成的。這樣市場營銷部門就可以評估一系列功能並將其放進一個個袋子里，並根據市場趨勢對它們進行排隊。將一個大特徵分解為六周的時間線可能會帶來挑戰，但有幾個重要的原因：

較小範圍和時間表的推理要容易得多

如果項目的業務價值微薄，它可以讓項目發揮重要作用

它允許三人小組效率更快

一個六個月的項目主要里程碑可能看起來像這樣：

Alpha版發布（6周）

Beta版發布（6周）

Feature Launch v1.0（6周）

Feature Launch v1.0.1（6周）

我應不應該分支功能分支？

答案是：不。

不要將功能分支分開。技術領導的目標應該是讓他們的團隊將他們手裡的功能分支直接提交給開發人員，而不是另一個與開發人員保持同步的功能分支。

長壽命的功能分支通常會引入代碼依賴性和其他編程模式，這些模式會面臨難以保持同步的分支問題。相反的，技術主管應該將他們的項目置於特徵標誌之後，並不斷將其與開發者合併。

總而言之，Webflow有兩個主要分支：

開發分支

主功能分支

其中，特徵分支

可能來自：dev

必須合併回：dev

功能標誌

我們鼓勵我們所有的工程師每天都推送代碼（如果可能的話），並且為了防止新功能讓用戶不適應，我們建議技術領導將這些新功能後面放置可以切換的「功能標誌」，同時放置如「點此獲得幫助」的概要性介紹。

我們承認可能有一些功能承諾可以被長期使用的情況。但「可能」也意味著，可能在1％的情況下我們需要重構最基本、最重要的那部分內容。所以，「可能」在某種情況下也意味著「基本不會」。

如果需要這樣一個分支機構，請告知整個團隊，你的產品經理和你的工程經理你的意圖。你可能會驚訝於如何將這項工作組織成規模較小且不斷合併的分支機構。

我怎樣才能保持「專註」？

保持「專註」意味著你首先關心自己，找到解決問題的「快樂」之處。生活就是要進行儘可能多的有意義的工作，而不僅僅是進行有意義的人類活動。

這意味著在日常工作中，需要時不時地休息一下，並參與讓你保持新鮮感和專註的活動。有沒有考慮或實施過下面的方法，比如：閱讀一本書，看Netflix影片，鍛煉，或去外面呼吸新鮮空氣。找到一個能讓你保持工作和生活點的例行公事，不要害怕向你的經理表達這些需求，也不要害怕為他們騰出時間，即使你可能覺得這些事件正在削減你的生產力。

如果你無法做得到專註，那隊伍也很可能不會有凝聚力，你要做到身體力行。

我如何保持有條理性？

新技術領導者感到不知所措，有這樣情況的原因往往是，他們可能沒有完成某些工作。（當然，我們中的一些人可以跨越這個階段，但對大多數人來說這卻是一個躲不開的經歷）。

學習並運用時間管理的藝術有助於減輕壓力。具體來講，可以通過多種方式來實現，並通過經驗總結來形成自己的經驗體系。

如果你從未閱讀過時間管理方面的書，我們建議你先從David Allen的Getting Things Done開始。閱讀此書有助於學習如何將頭腦中的雜音清理出去。如果他的方法不適合你，那就找別的方法，如果有效，可以把它與他人分享。

我應該被期望寫多少代碼？

這取決於項目，但一個可行的估計方式是，在整個項目的30％的時間內（或者更少）進行編碼，30％的時間（或者更多）檢查代碼，並用剩餘時間為項目團隊提供服務。

代碼審查

你要對最終可交付成果的質量負責，也因此你需要審核並在每個項目報告上簽字。這樣的檢驗機制對於大型團隊的工作來說會非常耗時，所以最好鼓勵團隊進行內附代碼審查。也就是說，指導團隊成員（無論是初級團隊還是高級團隊）來進行代碼審查，並將指導視為一個讓你進一步掌握自己技能的機會。

我如何向All Hands和Lattice提供狀態報告？

每周四上午11點（截至撰寫本文時），Webflow都會舉行一次「全員參與」會議，屆時管理團隊將傳達所有Webflow正在進行的項目以及大型公司目標和舉措的狀態。技術主管有責任在本次會議之前將其項目的進度更新提供給Webflow項目跟蹤器Google文檔。文檔在Slack的＃all-hands頻道中共享，更新的模板位於Google文檔的末尾。該模板中的項目有：

TDLR，該項目狀況的簡要介紹。

MILESTONE ON-TRACK / OFF-TRACK，你可以為每個活動里程碑提供跟蹤報告，其百分比進度以及前一周的百分比變化（這些是猜測），也可以列出團隊將在未來兩周內完成的任務和預計的交付日期。

關鍵決策，你提到任何導致時間表更改的重大決策，範圍更改以及與支持/市場營銷或資源更改有關的任何事項。

風險，未知和封鎖，你可以提上周以來出現的任何風險，未知或阻撓團隊前進的東西。

Lattice工具

Webflow使用Lattice工具幫助追蹤更高層次的公司目標。除了你的每周All Hands更新外，我們還會要求你對分配給你的Lattice目標進行更新。如果你沒有帳戶，請聯繫你的工程經理。

我如何保持團隊的積極性？

提出進步意識，為創造性地解決問題提供足夠的空間，而不僅僅是「蘿蔔加大棒」的激勵方式。我們是有主觀能動性的生物，很多事情都沒那麼複雜：將期望達成的目標、工具及方法路徑指出來，就會收穫結果。

這裡是我們流程的一些基本機制：

自治，掌握和目的

Daniel Pink在他的書《驅動力》（Drive）中否定了人類是由外部因素（比如金錢或更好的辦公室，職位等等外部因素）驅動的說法。相反，他發現我們受內部動機（例如被賦予歸屬感，提高技能的機會，並且按照我們自己的條件這樣做）因素驅動。這三個內在因素可以歸結為自治、掌握和目的，並且是解析動機基礎的極好起點。

提供這些關鍵激勵因素的職責一部分落在Webflow的肩膀上，但聰明的技術主管也可以使用它們來產生很大的影響。所以，每周都問問自己下面這些問題：

我是否給予我的團隊足夠的空間，讓成員用自己的方式解決問題？我是否在應該指代指導和意圖時明確地給予了指令？[自治]

我是否將團隊成員安排在他們可以正確成長的位置上了？[掌控]

針對世界上出現的一些問題，我是否對Webflow進行了功能性的調整？[目的]

提供反饋

從哈佛畢業後在谷歌和蘋果擔任執行官的Kim Scott在她的《Radical Candor》一書（此書還未在國內出版）中就如何最好地管理與團隊中每個人的關係和期望進行了陳述總結。

事實證明，我們不應該淡化我們的感受以及我們對彼此的看法，相反，我們應該以充滿人文關懷的方式來就問題進行討論。這項原則的基本前提是「給予關注，直面問題」。這意味著，你必須讓你的團隊知道：你理解、體諒他們，同時證明你對團隊及團隊中個人利益的關心，同時仍向他們提供重要的反饋（雖然可能會使成員不開心或利益受損）。

儘早經常性地提供重要的反饋意見、表示你對團隊成員的關心，會使你在未來的道路上避開許多必須面對的災難性挑戰。此外，反饋意見及表示關心不僅適用於消極情況，同樣也適用於積極情況。因為無論情況是好是壞都是重要的。

專業提示：我們框架反饋的方式可以改變接收效果。要就事論事，而非就事論人，綜合考慮這種結構中的使用場景，表現及影響模型。它的工作原理如下：找到問題發生的場景，將表現及影響單獨拿出來處理。例如這樣：「在今天的會議中，你多次打斷了Brian，讓Brian覺得他直到會議結束時才能發言，表述他的想法。這讓會議比實際所需要的時間更長。」

流動性

使團隊中每位成員都有崗位調整的可能性非常重要。提供潛在的機會本身就足以讓大多數人在工作和生活中感到幸福。這是激勵和工作效率的關鍵因素，因此我們在此特別就其進行提醒。

我的團隊中有一位表現不佳的成員。我該怎麼辦？

你有沒有聽過這句古老的格言：「沒有糟糕的員工，只有糟糕的經理？」呃，這句話在大部分情況中是符合實際的。Webflow僱傭了才華橫溢的工程師，因此，在你作出任何關於表現欠佳的問題的結論之前，確保你為團隊提供了100％的服務。

每個團隊成員都必須有足夠的動力，有充分的機會為自己創造有意義的進步，擁有自主空間和獲得感。因此，提供持續的反饋也是激勵團隊的一個重要組成部分。

你也必須考慮團隊成員的內在工作生活。問如「事情怎麼樣？工作之外的一切都順利嗎？」之類的問題是沒問題的，並且你應該經常這麼辦，但請記住把握好尺度，不要打探個人隱私。在記住個人問題的同時，給你的團隊成員討論個人問題的空間。

如果你已經盡最大努力為你的團隊成員創造適合他們工作的環境，並且他們仍然沒有達到你的期望，那就與你的經理聊聊下一步該做什麼吧。

我怎樣才能避免毀掉我的團隊？

如果一個團隊無法完成最後期限，這是一個管理問題，而不是團隊的問題。這意味著，在這個過程中的某個地方，這個項目沒有按計划進行，項目計劃也沒有得到及時糾正。

因此，避免職業倦怠的第一條規則是「很好地管理項目和期望」。

第二條規則：永遠不要在還沒考慮好就向團隊提問（而且你不能讓自己上夜班和周末）。

其他組織可能會要求他們的團隊在遇到困難時加班工作。但是團隊應該是一個長期性的團隊，要注意長期的效率。Webflow深深關注其團隊，不僅在專業上，而且在個人方面，所以我們必須盡我們所能來好好管理我們的時間。

關鍵時刻

哦，關鍵時刻到了，最好的團隊已經得到了，但還有不可避免的問題會出現。

作為一名技術主管，你將不可避免地遇到一個即將到期的截止日期，並且可能需要稍微付出一些努力才能使團隊在最後階段把項目拿出來。所謂的「稍微」意味著你的團隊可能需要在每周40小時的工作時間內多花幾個小時。

這樣的話就對了，我們的「緊縮」版本並不需要在晚上和周末各種加班，通常只在極少數的情況下這麼做。一個人一天的高效率工作時間通常只有2-4小時，在此時間之外，很難做到不出錯的做好工作。Webflow作為一家公司，要求他們做更我的工作收穫的會是嚴重的收益遞減（效率下降），同時也會使工作的人員感受十分糟糕。

加班趕工是真實存在的，但也可能是管理不佳的一個表現。我們必須盡最大努力將這些過度緊張的時期限制在每年一到兩次。

推薦書目

Flow

Deep Work

Drive

Leaders Eat Last

The Manager』s Path

The Progress Principle

Getting Things Done

Getting To Yes

Radical Candor

Search Inside Yourself