本文的作者Eliot Horowitz是MongoDB的創始人和技術總監。
在一個科技公司裡，軟體技術經理用在程式設計上的時間應該不低於總工作時間的30%。無論是管理一個團隊，還是一個分部，還是整個公司，當技術經理用在程式設計上的時間低於30%時，他執行職責的能力就會發生嚴重退化。
我的這個斷言可能跟那些我看到的想成為團隊首領的軟體程式設計師們期望的情況完全相反。每次晉升，程式設計師們都期待花在編碼上的時間會大幅度減少，當從“leader”爬到“經理”職位時，就應該徹底脫離編碼活動。而且，他們期望以一種“動口/眼不動手”的方式來保持對程式碼庫的熟悉。再上級的領導就跟編碼完全沒關係了(如果有的話)。
大概一年前，當時我的時間被越來越多的其它事情佔用，例如招聘，管理，開會等；我就發現，作為一個技術首領，當花在程式設計上的時間低於某個比例後，管理效果和工作效率就會出現問題。之前我寫過一篇短部落格闡述過這種體驗和觀點，但沒有展開具體的描述。這裡，我將會對這個觀點展開更詳細的論述。
為什麼要堅持程式設計活動
很多人認為，做為管理者，應該退出戰鬥第一線，專注於大戰略和管理工作。當然，管理者把大部分的時間用在這種事情上是應該的。但是，在我們這樣一個行業裡，因為我們允許或要求管理者幾乎不再去程式設計，現實讓我們付出了沉重的代價。一旦一個人停止編碼，他和程式設計師們關心的事物之間的重要聯絡就會退化。當這種情況發生時，決策，計劃和幹群關係就會出問題，從而瓦解了將技術人員提升到管理職位的良好願望基礎。
專案開發評估能力
程式設計師的百寶箱中最重要的一個絕活就是估計工期。如果沒有準確預估的能力，整體計劃是不可能正確的出臺的。大家也知道，做為一個族群，程式設計師們對工期的估計是臭名昭著的。糟糕的不能再糟，事實上，當從程式設計師口中得到一個預估的數字後，公認的方法是將它乘以二。通常，程式設計師都會對開發工作抱有非常樂觀的態度，但如果我們使用“estimate traction”理論，就會發現，程式設計活動表現出特別易變的特徵。因為我可以用很多方法實現一個功能，當我們在還沒有深入細節之前，我們的估計就是不可靠的。
技術債務
另外一個事情是，技術經理必須對技術債務給專案造成的影響掌握第一手的資料。如今，技術債務這個術語非常流行，常被用來當作爭論是優先開發新功能還是先重構老程式碼的彈藥。對“技術債務”這個詞的內涵熟悉的人通常最容易發起論戰。作為技術經理，你不僅僅是要熟悉這個概念，它們會在你判斷何時償還技術債務的決策中起直接作用。經常寫程式碼的經理擁有更多更有價值的資訊來判斷何時/如何做出這樣的決策。
知情的連續性
我並不是隨意選擇30%的比率的。我是基於自己的經驗，將足夠的時間參與到開發活動中，你很容易就能時刻掌握程式碼庫的任何變化。如果時間太少，你對開發動態的掌握就是斷斷續續，無法連成線。一旦斷了線，我就需要重新理順脈絡，由此得到的懲罰就是浪費了額外的時間。
分擔責任
作為負責人，你不可能讓所有決策都由你制定或由你批准。但你需要了解所有決策的前因後果和背景知識，來輔助這些決策。最終，你要為這些決策的後果負責，你對專案情況的掌控能力要能匹配你的這份責任。
積極參與程式設計贏得團隊尊敬
大家需要明白：要想成為一個成功的經理，你需要為團隊成員提供服務，促進開發，確保他們完成任務。我曾在一篇部落格裡寫過如何診斷和修復經理們有問題的幹群關係。但是對於的管理程式設計師來說，你需要熱愛程式設計。因為你的團隊在程式設計，如果你在程式設計上做榜樣，他們都會對你肅然起敬。
達到30%的障礙
儘管付出了最大努力，我仍然在保持30%的編碼時間上遇到了很多的阻礙。包括下面這些：
工作繁多：在一個創業公司裡，你總有忙不完的工作需要去做，即使在公司有規模、壯大後，如何對眾多都很重要的事情排優先順序也是一種考驗。技術經理有很多職責，完全會佔滿他的70%的時間。下面就是一些：
- 領導和照顧團隊：這是一個技術經理的第一要務。你已經不能夠只為自己的工作負責，你要為你的團隊能保持最好的工作狀態負責。指導團隊任務，解決紛爭，思考如何優化工作條件來提高工作效率和舒適度，這都需要時間。
- 做決策：隨著職權的增加，技術經理需要花更多的時間放在各種各樣戰略上的統籌和計劃等事務上。起初，也許只是一些技術方面的決策，但之後，產品開發和競爭策略方面的事務將會佔去很大一部分。
- 招聘：經理，總監，副總們，CTO都需要組建自己的團隊，有時需要迅速組建。一個好的招聘高手能帶來很大幫助，技術經理在這樣的事情上的作用是無可替代的。好的技術經理會活躍的跟上級保持溝通，不斷的將自己團隊中的優秀人士推薦出去。
- 客戶：隨著技術經理職權的增加，他們經常會對外拋頭露面。他們會被帶去參加“推銷會”，期望他能帶去一些有深度的話語。或當重要客戶不高興時被叫去滅火。
- 公關：資深技術經理會把一部分時間奉獻給公開演講，寫部落格，或者報刊上發表文章。不論你在這些活動中出了多少力，這些寫作、編輯、排練、差旅、出席活動等都是花費時間的。
奪回時間：上面我說的這些活動都是一個技術經理應該投入時間的事情。下面要說的是我從經驗中發現的一些陷阱，是它們在阻擋我努力保持20%最低限度的編碼時間，至今仍站在我面前，妨礙我重回30%的目標。
- 不勇於說不：高成就意味著要努力工作；然而，做事要穩妥，一個技術經理最重要的職責就是，當你的團隊負擔過重或接近這種狀態時要勇於說不。如果你這個時候不說不，其他人就會開始對你的計劃和工期承諾指手劃腳。
- 開會：有一個巨大的家庭手工業行業都在為如何高效的開會出謀劃策，這是有其自身原因的。我的職業生涯中浪費在會議中的時間算是最多的了。尤其是不斷的面試或出席必須由團隊首領出席的會議。
失敗的策略
當在探索如何奪回我的編碼時間時，有很多的方法並不奏效。
- 少睡：這種方式雖然對我有巨大的誘惑，但其實犧牲睡眠時間沒有一點效果。你的大腦需要休息，缺少睡眠會影響情緒並降低工作效率。
- 只看標頭檔案：我以為這種方法可行，但實踐中，只看提交的C++程式碼的標頭檔案對你的管理工作的幫助甚少。
- 專一：作為團隊首領，你只關注程式碼庫裡的一個專案也許是可以的，但對於總監或更高階別的人來說，你應該對負責的所有東西都要熟悉、瞭解。
- 委託：有時候為了多做工作，會將一些事情隨意的交給他人做，但實際上一些像寫報告這樣的事情你一定要認真囑咐才行。
成功的策略
儘管走了很多死衚衕，我還是發現了一些成功的方法：
- 時間分段：我的日程表上沒有被預先分配的時間是非常少的。想起來這也是很顯然的。於是我專門為程式設計特地分出一些時間段。實踐中，這些時間段經常會被重新調整，雖然每週只擠出8小時，效果是完全不一樣的。
- 委派：委派要有技巧，尤其是在你對如何執行抱有強烈想法並有能力去做時。有很多原因導致一個經理反對將任務委託他人，但事實上每個原因都應該被當作一個現存的需要解決的問題，而不是一個不可逾越的障礙。沒有什麼比放手讓一個你信賴的人替你主持一個會議能釋放你更多的編碼時間了。
- 工作時間：將時間分段，工作時間裡儘量避免打擾。在這些時間段之間的時間裡，我會幹一些不重要或不需求注意力長期集中的事情。
最後幾招
下面是一些經驗建議，送給那些發現自己試圖達到30%但無法接近的技術經理們：
- 學習如何讀程式碼。跟寫程式碼比起來，這是一種完全不同的技巧。
- 指定會議流程，對會議程式保持控制。不參加任何沒有計劃的會議。
- 用一臺好用的電腦。你喜歡MacBook Air？不，別用它。
- 清楚如何訪問一個開發環境，這樣當有修改時可以快速測試。
- 記住你是把一小時分成5個時間段使用的人。如果有事情需要一小時，在日程表上標明。
- 20–30%是我自己的發現。你的也許跟我不同。評估你自己的(你修復一個緊急bug需要多少時間？你知道程式碼庫中麻煩最多的程式是哪一塊嗎？隨機找一段程式，看看你是否知道是做什麼的。如果不能，說明你需要更多的時間)。
- 分類列出哪些事情什麼時候做，哪些事情應該完成。(知道Getting Things Done (GTD)的人會看出這是提高工作效率的基本技巧。)
- 最後，我最近越來越喜歡把東西寫到紙上。跟感覺上相反，列印出來的說明，把一些需要排優先順序的任務列在紙上，或者是一段程式碼，經常的，它會成為把大量時間盯著螢幕的一種平衡。
我希望這些方法對你們有用。如果你有其它更好的技巧，請在評論裡告訴我。謝謝。